A produção da etapa de requisitos do processo de desenvolvimento de software é Especificações de requisitos de software (SRS) (também chamado de documento de requisitos ). Este relatório estabelece uma base para as atividades de engenharia de software e está em construção quando todos os requisitos são levantados e analisados. SRS é um relatório formal, que funciona como uma representação do software que permite ao cliente avaliar se o mesmo (SRS) está de acordo com suas necessidades. Além disso, compreende os requisitos do usuário para um sistema, bem como especificações detalhadas dos requisitos do sistema.

O SRS é uma especificação para um produto de software, programa ou conjunto de aplicativos específico que executa funções específicas em um ambiente específico. Ele atende a vários objetivos dependendo de quem o está escrevendo. Primeiro, o SRS poderia ser escrito pelo cliente de um sistema. Segundo, o SRS poderia ser escrito por um desenvolvedor do sistema. Os dois métodos criam situações totalmente diversas e estabelecem finalidades totalmente diferentes para o documento. O primeiro caso, SRS, é utilizado para definir as necessidades e expectativas dos usuários. O segundo caso, SRS, é escrito para diversos fins e serve como um documento contratual entre o cliente e o desenvolvedor.

Características de um bom SRS

A seguir estão as características de um bom documento SRS:

1. Correção: A revisão do usuário é usada para fornecer a precisão dos requisitos declarados na SRS. Diz-se que o SRS é perfeito se cobre todas as necessidades que são realmente esperadas do sistema.

2. Completude: A SRS está completa se, e somente se, incluir os seguintes elementos:

(1). Todos os requisitos essenciais, sejam eles relacionados à funcionalidade, desempenho, design, restrições, atributos ou interfaces externas.

calculando a posse no excel

(2). Definição das respostas do software a todas as classes realizáveis ​​de dados de entrada em todas as categorias de situações disponíveis.

Nota: É essencial especificar as respostas para valores válidos e inválidos.

(3). Etiquetas completas e referências a todas as figuras, tabelas e diagramas da SRS e definições de todos os termos e unidades de medida.

3. Consistência: A SRS é consistente se, e somente se, nenhum subconjunto de requisitos individuais descritos em seu conflito. Existem três tipos de possíveis conflitos no SRS:

(1). As características especificadas de objetos do mundo real podem entrar em conflito. Por exemplo,

(a) O formato de um relatório de resultados pode ser descrito num requisito como tabular, mas noutro como textual.

(b) Uma condição pode estabelecer que todas as luzes serão verdes, enquanto outra afirma que todas as luzes serão azuis.

(2). Pode haver um conflito razoável ou temporal entre as duas ações especificadas. Por exemplo,

(a) Um requisito pode determinar que o programa irá adicionar duas entradas, e outro pode determinar que o programa irá multiplicá-las.

(b) Uma condição pode afirmar que 'A' deve sempre seguir 'B', enquanto outra exige que 'A e B' ocorram simultaneamente.

(3). Dois ou mais requisitos podem definir o mesmo objeto do mundo real, mas usar termos diferentes para esse objeto. Por exemplo, a solicitação de um programa para entrada do usuário pode ser chamada de 'prompt' em um requisito e de 'sugestão' em outro. O uso de terminologia e descrições padrão promove consistência.

4. Inequívoca: A SRS é inequívoca quando cada requisito fixo tem apenas uma interpretação. Isso sugere que cada elemento é interpretado de forma única. Caso exista um método utilizado com múltiplas definições, o relatório de requisitos deve determinar as implicações no SRS para que seja claro e simples de entender.

5. Classificação por importância e estabilidade: O SRS é classificado quanto à importância e estabilidade se cada requisito nele contido tiver um identificador para indicar a importância ou a estabilidade desse requisito específico.

Normalmente, todos os requisitos não são igualmente importantes. Alguns pré-requisitos podem ser essenciais, especialmente para aplicações críticas, enquanto outros podem ser desejáveis. Cada elemento deve ser identificado para tornar essas diferenças claras e explícitas. Outra forma de classificar os requisitos é distinguir as classes de itens como essenciais, condicionais e opcionais.

6. Modificabilidade: O SRS deve ser tão modificável quanto possível e deve ser capaz de obter rapidamente alterações no sistema até certo ponto. As modificações devem ser perfeitamente indexadas e com referências cruzadas.

diferença simétrica

7. Verificabilidade: O SRS está correto quando os requisitos especificados podem ser verificados com um sistema econômico para verificar se o software final atende a esses requisitos. Os requisitos são verificados com a ajuda de análises.

8. Rastreabilidade: O SRS é rastreável se a origem de cada um dos requisitos for clara e se facilitar a referência de cada condição em documentação futura de desenvolvimento ou melhoria.

Existem dois tipos de Rastreabilidade:

1. Rastreabilidade retroativa: Isto depende de cada requisito referenciar explicitamente a sua fonte em documentos anteriores.

2. Rastreabilidade direta: Isto depende de cada elemento do SRS ter um nome ou número de referência único.

A rastreabilidade futura do SRS é especialmente crucial quando o produto de software entra na fase de operação e manutenção. À medida que o código e o documento de projeto são modificados, é necessário ser capaz de determinar o conjunto completo de requisitos que podem ser abrangidos por essas modificações.

9. Independência de projeto: Deve haver uma opção para selecionar entre múltiplas alternativas de design para o sistema final. Mais especificamente, a SRS não deve conter quaisquer detalhes de implementação.

10. Testabilidade: Um SRS deve ser escrito de forma que seja simples gerar casos de teste e planos de teste a partir do relatório.

11. Compreensível pelo cliente: Um usuário final pode ser um especialista em seu domínio explícito, mas pode não ter treinamento em ciência da computação. Conseqüentemente, o propósito de notações e símbolos formais deve ser evitado tanto quanto possível. A linguagem deve ser mantida simples e clara.

12. O nível certo de abstração: Se a SRS for escrita para a fase de requisitos, os detalhes deverão ser explicados explicitamente. Considerando que, para um estudo de viabilidade, menos análises podem ser utilizadas. Assim, o nível de abstração se modifica de acordo com o objetivo do SRS.

Propriedades de um bom documento SRS

As propriedades essenciais de um bom documento SRS são as seguintes:

Conciso: O relatório SRS deve ser conciso e, ao mesmo tempo, inequívoco, consistente e completo. Descrições detalhadas e irrelevantes diminuem a legibilidade e também aumentam as possibilidades de erros.

supw

Estruturada: Deve ser bem estruturado. Um documento bem estruturado é simples de entender e modificar. Na prática, o documento SRS passa por diversas revisões para atender às necessidades do usuário. Freqüentemente, os requisitos do usuário evoluem ao longo do tempo. Portanto, para facilitar as modificações no documento SRS, é fundamental deixar o relatório bem estruturado.

Visualização de caixa preta: Deve apenas definir o que o sistema deve fazer e abster-se de indicar como fazê-lo. Isto significa que o documento SRS deve definir o comportamento externo do sistema e não discutir as questões de implementação. O relatório SRS deve ver o sistema a ser desenvolvido como uma caixa preta e deve definir o comportamento visível externamente do sistema. Por esta razão, o relatório SRS também é conhecido como especificação de caixa preta de um sistema.

Integridade conceitual: Deve mostrar integridade conceitual para que o leitor possa apenas compreendê-lo. Resposta a eventos indesejados: Deve caracterizar respostas aceitáveis ​​a eventos indesejados. Estas são chamadas de resposta do sistema a condições excepcionais.

Verificável: Todos os requisitos do sistema, conforme documentados no documento SRS, devem estar corretos. Isto significa que deveria ser possível decidir se os requisitos foram ou não atendidos em uma implementação.