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 830-1998 IEEE Melhores Práticas para Especificações de Requisitos de Software (ERS)

2 IEEE Std 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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 830-1998 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