A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


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 Conteúdo Conteúdo Escopo Escopo Definições Definições Considerações para produzir uma boa ERS Considerações para produzir uma boa ERS As partes de uma ERS As partes de uma ERS

3 IEEE Std Escopo Escopo Indicar as Melhores Praticas para escrever as Especificações de Requisitos de Software; 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. 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 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; 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; Cliente: Quem paga pelo produto e que usualmente define os requisitos; Fornecedor:Quem produz produto para o Cliente; Fornecedor:Quem produz produto para o Cliente; Usuário: Quem opera ou interage diretamente com o produto. Usuário: Quem opera ou interage diretamente com o produto.

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

6 IEEE Std Natureza da ERS: 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; 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. 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 Ambiente da ERS: Ambiente da ERS: É importante salientar que a ERS considera uma visão em alto nível do projeto. É 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. 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 Ambiente da ERS: 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: O desenvolvedor deve atentar para não levar adiante o processo de desenvolvimento até que a ERS esteja corretamente finalizada, ou seja: a) A ERS define corretamente os Requisitos de Software; b) Não descreve qualquer detalhe de projeto e implementação de Software; c) Não impõe restrições adicionais ao Software.

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

10 IEEE Std Preparação Conjunta de uma ERS: 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á; 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. 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 ERS – Evolução: ERS – Evolução: a) Os requisitos devem ser especificados o mais completamente possível para o momento, prevendo revisões inevitáveis; b) 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ótipo: Protótipos facilitam o feedback do cliente; Protótipos facilitam o feedback do cliente; Protótipos mostram antecipadamente aspectos do comportamento dos sistemas; 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. ERS baseadas em protótipos tendem a sofrer menos alterações durante o desenvolvimento, portanto encurtam o tempo de desenvolvimento.

13 IEEE Std ERS e Projeto: ERS e Projeto: Um requisito especifica externamente uma função visível ou um atributo de um sistema; 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; 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. 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. A ERS especifica que funções são desempenhadas, que dados produzir, que resultados e qual local para os mesmos.

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

15 IEEE Std ERS e Requisitos de Projeto: 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: 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: a) Custos e datas de entrega; b) Relatórios; c) Métodos de desenvolvimento de software; d) Garantia de qualidade; e) Critérios de Validação e Verificação; f) Proceedimentos de aceitação

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

17 IEEE Std Introdução (Seção 1 da ERS): 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: A introdução da ERS deve prover uma visão geral do conteúdo da ERS. Deve conter os seguintes itens: a) Proposta; b) Escopo; c) Definições, acrônimos e abreviaturas; d) Referências; e) Visão Geral.

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

19 IEEE Std Requisitos Específicos (Seção 3 da ERS): 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. 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 Informações de Suporte: Informações de Suporte: São informações que tornam a ERS um documento fácil de utilizar. Deve conter: São informações que tornam a ERS um documento fácil de utilizar. Deve conter: a) Conteúdo; b) Índice; c) Apêndices.


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

Apresentações semelhantes


Anúncios Google