1 / 25

DIRETRIZES PARA ESPECIFICAÇÃO DOS REQUISITOS DO SOFTWARE

DIRETRIZES PARA ESPECIFICAÇÃO DOS REQUISITOS DO SOFTWARE. (IEEE std 830/1984) Disciplina: Engenharia de Software I Profª: Thelma e Marcelo. IEEE.

minowa
Download Presentation

DIRETRIZES PARA ESPECIFICAÇÃO DOS REQUISITOS DO SOFTWARE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DIRETRIZES PARA ESPECIFICAÇÃO DOS REQUISITOS DO SOFTWARE (IEEE std 830/1984) Disciplina: Engenharia de Software I Profª: Thelma e Marcelo

  2. IEEE • Institute of Electrical and Eletronics Engineers.Criada pelo Instituto de Engenheiros Elétricos e Eletrônicos /NY/USA – usada como padrão metodológico. • Normas utilizadas como roteiro para a criação da Especificação dos Requisitos do Software (ERS/SRS) – 1º documento gerado pelo processo de análise de sistemas dedicado ao software.

  3. INTRODUÇÃO • Análise de Sistemas: • Identificação das necessidades do usuário • Avaliação da viabilidade • Alocação recursos • Limites de custo e tempo • Criação de uma definição do sistema – fundamento para o trabalho de desenvolvimento

  4. ANÁLISE DE REQUISITOS • Levantamento dos dados, entrevistas • Reconhecimento do problema • Detalhamento e refinamento dos objetivos • Descrição do produto – 1ª visualização da solução • Especificação dos requisitos • Revisão

  5. ERS • Documento que permite ao cliente descrever suas necessidades e ao desenvolvedor compreendê-las. • Define todos os requisitos que devem compor o software. • Estabelece uma base para o acordo entre clientes e desenvolvedores sobre o que o software fará.

  6. RECOMENDAÇÕES... • NATUREZA DA ERS • É uma especificação de produto de software que realiza certas funções em um ambiente específico. • Funcionalidade: O que o software pretende fazer? • Interfaces Externas: Como o software interage com as pessoas, hardware, outros hardwares, outros softwares • Performance: como deve ser a velocidade, disponibilidade, o tempo de resposta , tempo de recuperação das várias funções do software • Atributos: considerações sobre portabilidade, manutenibilidade, segurança? • Limites impostos: linguagem de programação, integridade do BD, limitação de recursos, ambientes operacionais

  7. RECOMENDAÇÕES • AMBIENTE DA ERS: (circunstâncias) • Definir corretamente os requisitos • Não descrever qualquer detalhe de implementação • Não estabelecer limites adicionais

  8. CARACTERÍSTICAS... • Uma ERS é: • Correta: quando cada requisito expresso nela for encontrado no software também; • Não Obscura: quando cada requisito declarado nela tiver uma só interpretação; deve ser clara; sem erros de linguagem. • Completa: quando contém todos os requisitos significantes; definição de todas as entradas e saídas; definição e referência de todas as tabelas, figuras, diagramas, termos e unidades de moeda; quando não há TBD (to be determined)

  9. CARACTERÍSTICAS • Consistente: quando não há conflito entre os requisitos; • Estabelecer Grau de Importância: quando cada requisito identificar seu grau de importância em relação a outro (uns são essenciais, outros desejáveis); • Verificável: quando for possível checar cada requisito; • Modificável: quando os requisitos podem ser facilmente alterados completamente e consistentemente; • Rastreável: quando o código e o desenho são modificados é possível rastrear para frente e para traz para acertar a ERS.

  10. PARTES DA ERS • 1ª PARTE: 1. Introdução 1.1 Objetivo Geral 1.2 Escopo 1.3 Definições, Siglas e Abreviações 1.4 Referências 1.5 Visão Geral

  11. 1. INTRODUÇÃO • Deve fornecer uma visão geral da ERS inteira. 1.1. OBJETIVO GERAL • Delinear o objetivo da ERS • Especificar o público alvo 1.2. ESCOPO • Delinear os objetivos específicos; • Identificar o produto do software a ser produzido; • Explicar o que o produto de software fará e o que não; • Explicar os benefícios relevantes;

  12. 1. INTRODUÇÃO 1.3. DEFINIÇÃO, SIGLAS E ABREVIAÇÕES • definições de termos, siglas e abreviações necessárias para interpretar apropriadamente a ERS. 1.4. REFERÊNCIAS • Lista completa de todos os documentos referenciados; • Identificação de cada documento contendo título, nº, data, etc. • Especificação das origens das referências; • Os documentos referenciados devem estar no Apêndice.

  13. Número Título Data da aquisição Responsável pelo fornecimento 1 Ficha de controle de freqüência 27/02/2003 Maria Ap. M. de Moraes (Diretora de serviço) 2 Declaração de encargos de família para imposto de renda 27/02/2003 Maria Ap. M. de Moraes (Diretora de serviço) Exemplos • Siglas: • SILAF – Sistema de Lançamento para Folha de Pagamento • Base de dados – grande quantidade de informações armazenadas • Núcleo de Pessoal – Recursos Humanos • Exemplos de Referências

  14. 1. INTRODUÇÃO 1.5. VISÃO GERAL • Descrever o que o restante da ERS contém; • Explicar como a ERS está organizada.

  15. PARTES DA ERS • 2ª PARTE: 2. Descrição Global 2.1. Considerações Iniciais 2.2. Perspectivas do Produto 2.3 Funções do Produto 2.4. Características do Usuário 2.5. Limites 2.6. Suposições de Dependências 2.7. Requisitos adiados 2.8. Estudo de Viabilidade

  16. 2. DESCRIÇÃO GLOBAL • Descreve fatores gerais do produto e seus requisitos. Fornece uma base para posterior detalhamento dos requisitos específicos. 2.1 Considerações Iniciais • Descrição da Empresa; • Histórico; • Ramo de Atividade; • Descrição do Setor de Informática.

  17. 2. DESCRIÇÃO GLOBAL 2.2. Perspectiva do Produto • Coloca o produto em perspectiva com outros produtos. Pode incluir: • Interfaces do Sistema: com o que o produto interage • Interfaces do Usuário: formatos de telas, relatórios ou consulta • Interfaces de Hardware:como o produto interage com o hardware; características de configuração;

  18. 2. DESCRIÇÃO GLOBAL 2.2. Perspectiva do Produto • Interfaces de Software: deve especificar o uso de outros softwares (BD,SO, software p/ capturar imagem,etc) • Interfaces de Comunicação: especificar os protocolos de redes locais, etc; • Limites de Memória: especificar as características e os limites de memória primária e secundária;

  19. 2. DESCRIÇÃO GLOBAL 2.2. Perspectiva do Produto • Operações: deve especificar requisitos de operações normais e especiais como rotinas de inicialização, processamento, backup’s e restauração; • Requisitos para adaptação de situação: especificar situações em que o software deve ser adaptado antes da instalação.

  20. 2. DESCRIÇÃO GLOBAL 2.3. Funções do Produto • Fornecer uma relação das funções do sistema através de textos, detalhando cada campo; • Atenção na clareza. 2.4. Características do Usuário • Descrever nível educacional, experiência e habilidade técnica.

  21. Exemplos de Funções do Produto • Cadastrar usuários: Cadastra-se todos os usuários que terão acesso ao sistema. Podendo ter dois níveis de acesso: Administrador e usuário simples. Assim, alguns campos como login, senha e nível de acesso devem ser preenchidos. • Exportar dados para outros aplicativos: Essa função permitirá a exportação dos dados relativos aos funcionários para que outros aplicativos possam usar essa base de dados. Esses dados poderão, por exemplo, ser usados no Word para gerar comunicados, notícias entre outras coisas.

  22. 2. DESCRIÇÃO GLOBAL 2.5. Limites, Suposições e Dependências • Deve fornecer uma descrição geral de qualquer outro item que limitará as opções do desenvolvedor. Ex: • Normas reguladoras; Limitações do hardware; Interfaces com outras aplicações; Linguagem de programação; Protocolos; Requisitos de segurança, etc. • fatores que afetam os requisitos expressos na ERS

  23. Exemplo... • O limite para que esse sistema não tenha sua funcionalidade completa seria a não aquisição do ponto eletrônico e também se os computadores não pudessem ser ligados em rede. • A não aquisição do ponto eletrônico fará com que o sistema não tenha o seu total desempenho, pois a entrada de dados será feita manualmente, inserindo somente as exceções do ponto diário, ou seja, a falta dos funcionários.

  24. 2. DESCRIÇÃO GLOBAL 2.6. Requisitos Adiados • Identificar os requisitos que podem ser adiados até as versões futuras do sistema. 2.7. Estudo de Viabilidade • Incluir a viabilidade técnica e econômica

  25. 3.REQUISITOS ESPECÍFICOS • 3.1Modelo Essencial • 3.1.1 Modelo Ambiental • Diagrama de Contexto • Lista de Eventos • 3.1.2 Modelo Comportamental • Modelo Conceitual • Diagrama de Fluxo de Dados particionado • Lógica de Processos • 3.2 Requisitos de Interface Externa • 3.3 Requisitos de Performance

More Related