IEEE Std 830-1998 IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)

Apresentação em tema: "IEEE Std 830-1998 IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)"— Transcrição da apresentação:

1 IEEE Std IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)

2 IEEE Std 830-1998 Conteúdo Escopo Definições
Considerações para produzir uma boa ERS As partes de uma ERS

3 IEEE Std Escopo Indicar as Melhores Praticas para escrever as Especificações de Requisitos de Software; Descrever o Conteúdo e a Qualidade de uma boa Especificação de Requisitos de Software (ERS) e apresentar diversas amostras de esboços de ERSs.

4 IEEE Std Definições Contrato: Um documento oficial firmado entre o Cliente e o Fornecedor que indica os requisitos técnicos e organizacionais (prazo, custo, risco do projeto, etc) referentes ao produto final; Cliente: Quem paga pelo produto e que usualmente define os requisitos; Fornecedor:Quem produz produto para o Cliente; Usuário: Quem opera ou interage diretamente com o produto.

5 IEEE Std 830-1998 Considerações para Produzir uma boa ERS
Natureza da ERS Ambiente da ERS Características de uma boa ERS Preparação Conjunta da ERS ERS - Evolução Protótipo ERS e Projeto ERS e Requisitos de Projeto

6 IEEE Std 830-1998 Natureza da ERS:
A ERS é uma especificação para um software particular, programa ou conjunto de programas que desempenham funções específicas dentro de um ambiente; Os tópicos principais que um desenvolvedor de Software deve atentar são: Funcionalidade, Interfaces Externas, Desempenho, Atributos e Restrições de Projeto impostas na Implementação.

7 IEEE Std 830-1998 Ambiente da ERS:
É importante salientar que a ERS considera uma visão em alto nível do projeto. No caso de subsistemas, a ERS deverá definir as interfaces do sistema com sua porção de software e obterá desempenhos externos garantindo os requisitos de funcionalidades da porção.

8 IEEE Std 830-1998 Ambiente da ERS:
O desenvolvedor deve atentar para não levar adiante o processo de desenvolvimento até que a ERS esteja corretamente finalizada, ou seja: A ERS define corretamente os Requisitos de Software; Não descreve qualquer detalhe de projeto e implementação de Software; Não impõe restrições adicionais ao Software.

9 IEEE Std 830-1998 Características de uma Boa ERS: Correta;
Sem ambigüidades; Completa; Consistente; Priorização por importância e/ou estabilidade; Verificável (testes); Modificável (sem alterar atributos); Rastreável (Documentação/Controle de Versões);

10 IEEE Std 830-1998 Preparação Conjunta de uma ERS:
O Processo de desenvolvimento de software deve se iniciar com um acordo entre cliente e fornecedor definindo de forma completa o que o software (produto) fará; Essa característica é importante pois usualmente nem o cliente nem o fornecedor estão aptos a especificar requisitos unilateralmente. O cliente não entende os detalhes de desenvolvimento enquanto o fornecedor não compreende a real necessidade do cliente.

11 IEEE Std 830-1998 ERS – Evolução:
Os requisitos devem ser especificados o mais completamente possível para o momento, prevendo revisões inevitáveis; Um processo formal de atualização de requisitos deve ser definido para possibilitar a identificação, controle, ajuste e reporte modificações

12 IEEE Std Protótipo: Protótipos facilitam o feedback do cliente; Protótipos mostram antecipadamente aspectos do comportamento dos sistemas; ERS baseadas em protótipos tendem a sofrer menos alterações durante o desenvolvimento, portanto encurtam o tempo de desenvolvimento.

13 IEEE Std 830-1998 ERS e Projeto:
Um requisito especifica externamente uma função visível ou um atributo de um sistema; Um projeto descreve um sub-componente particular de um sistema e/ou suas interfaces com outros sub-componentes; Todo projeto parte de um requisito mas nem todo requisito é projetado, por causa das restrições de implementação. A ERS especifica que funções são desempenhadas, que dados produzir, que resultados e qual local para os mesmos.

14 IEEE Std 830-1998 ERS e Projeto:
A ERS tem foco no serviço a ser desempenhado. Não especifica itens de projeto como os seguintes: Divisão do software em módulos; Alocação de funções a módulos; Descrição do fluxo de informações ou controle entre módulos; Escolha de estrutura de dados;

15 IEEE Std 830-1998 ERS e Requisitos de Projeto:
Requisitos de projeto representam um entendimento entre Cliente-Fornecedor sobre itens contratuais pertinentes a produção do software e portanto, não estão incluídos na ERS. Normalmente incluem: Custos e datas de entrega; Relatórios; Métodos de desenvolvimento de software; Garantia de qualidade; Critérios de Validação e Verificação; Proceedimentos de aceitação

16 IEEE Std 830-1998 As partes de uma ERS Introdução (Seção 1 da ERS)
Descrição Geral (Seção 2 da ERS) Requisitos Específicos (Seção 3 da ERS) Informações de Suporte

17 IEEE Std 830-1998 Introdução (Seção 1 da ERS):
A introdução da ERS deve prover uma visão geral do conteúdo da ERS. Deve conter os seguintes itens: Proposta; Escopo; Definições, acrônimos e abreviaturas; Referências; Visão Geral.

18 IEEE Std 830-1998 Descrição Geral (Seção 2 da ERS):
Descreve os fatores gerais que afetam o produto e seus requisitos. Deve conter: Perspectiva do Produto; Funções do Produto; Características de Usuário; Restrições; Suposições e dependências; Rateio dos requisitos.

19 IEEE Std 830-1998 Requisitos Específicos (Seção 3 da ERS):
Esta seção deve especificar os requisitos detalhadamente num nível que permita ao desenvolvedor e ao testador projetar sistema e procedimentos de teste que satisfaçam os requisitos.

20 IEEE Std 830-1998 Informações de Suporte:
São informações que tornam a ERS um documento fácil de utilizar. Deve conter: Conteúdo; Índice; Apêndices.