Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com
Roteiro Introdução Tipos de requisitos Atividades Princípios da Análise Especificação Análise Estruturada 2/16
Introdução Os requisitos de software é fundamental para o sucesso do projeto de software Análise de requisitos envolve um trabalho de descoberta, refinamento, modelagem e especificação das necessidades relativos ao software que se deseja desenvolver. Tanto o cliente quanto o desenvolvedor desempenham um papel de grande importância. Permite que o engenheiro de sistemas especifique as necessidades do software em termos de funções e desempenho Permite ao engenheiro de software (ou analista), a análise dos requisitos e a construção de modelos do processo, dos dados e dos aspectos comportamentais que serão tratados pelo software 3/16
Tipos de requisitos Requisitos dos usuários: declarações sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar Escrito para os gerentes do cliente, usuários finais do sistema, gerentes do fornecedor e desenvolvedores Requisitos do Sistema: estabelecem detalhadamente as funções e restrições do sistema (funcionalidades específicas do sistema, utiliza linguagem natural,notações gráficas ou métodos formais), muitas vezes servem de contrato entre o cliente e o desenvolvedor. Escritos para os usuários finais do sistema e desenvolvedores Especificação do Projeto de software: (fusão dos requisitos do usuário e do sistemas com maiores detalhes de implementação). Escrito para os desenvolvedores do software 4/16
Requisitos Funcionais (funcionalidades específicas, completeza e consistência); Descreve a funcionalidade do sistema detalhadamente, suas entradas, saídas, exceções, etc. Todas as funções requeridas pelo usuário devem ser definidas Não-funcionais (objetivos gerais, difícil de serem verificados e quantificados). número de transações processadas por segundo, o tamanho do sistema em bytes, a quantidade de memória necessária em bytes, o tempo de treinamento necessário para poder operá-lo, o tempo médio de falha, o tempo de reinício após uma falha e outros. 5/16
Atividades Análise da Informação (estuda o plano, revisa o escopo, interação do cliente projetista e desenvolvedores); Avaliação (informações, funções, comportamento e interfaces) e Síntese (uma ou mais soluções); Modelagem (elaborar modelo (protótipo) para melhor compreensão das informações e controle); Especificação dos Requisitos e Revisão (elaborar documento com todas as atividades); 6/16
Processos de Comunicação Desenvolvimento de software envolve: clientes, desenvolvedores, usuários e gerentes; Dificuldades gerais da análise de requisitos: os clientes não entendem de software ou de seu processo de desenvolvimento; o desenvolvedor não entende do sistema no qual o software vai executar. O gerente de software deve preencher esta lacuna. Realizando as seguintes ações: Ajudar no diálogo entre clientes e/ou usuários e desenvolvedor; Identificar e diferenciar expectativas e necessidades; Extrair boas e consistentes informações. 7/16
Princípios da Análise Domínio da Informação (dados ou eventos, entrada processamento saída). Existem três pontos de vista: Fluxo (transformações); Conteúdo (semântica); Estrutura (sintaxe). Modelagem representar informações, funções e comportamentos em uma notação gráfica (o que o software faz!!!); 8/16
Princípios da Análise (cont.) Visão Essencial (funções e informações sem detalhes de processamento). Por exemplo: ler estado do sensor; Vantagem: deixa em aberta a possíveis alternativas de implementação. Visão de Implementação (funções e informações do mundo real, acomodar detalhes de implementação).por exemplo: de que forma o sensor detecta a invasão; Vantagem: auxilia na definição de restrições. 9/16
Especificação Representado por um documento. Nas três seguintes formas: linguagem natural, gráfica ou protótipo; O documento deve mostrar aspectos funcionais, de informação e comportamentais; Para ser eficiente deve considerar os seguintes princípios: Separar Funcionalidade e Implementação Especificar usando linguagem orientada a processos; Representar ambiente, sistema e software; Mostrar a visão que os usuários terão do sistema; Permitir alguma validação; Deve ser localizada e fracamente acoplada. 10/16
Especificação (cont.) 11/16
Revisão da Especificação Realizado pelo cliente e desenvolvedor; A revisão é feita primeiramente de forma geral e depois de forma detalhada; Depois de completar a revisão, um contrato de software deve ser assinado; Solicitações de modificações, depois deste que o contrato é assinado, vai acarretar custo e ajustes no cronograma; Dificuldades: Testar a especificações; Avaliar impacto de modificações no requisito; 12/16
Análise Estruturada Desenvolvida nos meados dos anos 70 por Gane, Sarson e De Marco; Baseada em uma Notação Gráfica para representar dados e os processos que os modificam; Objetivos: Descrição (o que o cliente exige); Base para criar projeto de software; Definir requisitos. Elementos Básicos: Dicionário de dados; Diagrama Entidade-Relacionamento; Diagrama de Fluxo de dados; 13/16
Estudo de Caso Estudar o artigo Medição de Pontos por Função a Partir da Especificação de Requisitos Abstract. Neste trabalho apresentaremos uma proposta para medição de Pontos por Função a partir da especificação de requisitos expressa em casos de uso, notação UML (Unified Modeling Language). Com esta medição torna-se disponível uma métrica confiável na fase de especificação de requisitos do processo de desenvolvimento de software. Esta proposta visa enfatizar a importância da especificação de requisitos para o trabalho de medição de sistemas, minimizando o esforço dos líderes de projeto, obtendo uma compreensão intuitiva do porte do projeto em termos de Pontos por Função de maneira simples e dinâmica. Verifica-se que caso de uso e pontos por função podem ser usados juntos efetivamente para alcançar sucesso no gerenciamento dos requisitos e do projeto. 14/16
Bibliografia BIBLIOGRAFIA BÁSICA: PRESSMAN, R.S. Engenharia de Software. Mc Graw Hill, 5ª Edição 2001. SOMMERVILLE,I. Engenharia de Software. Addison Wesley, 6ª Edição 2003. REZENDE,D.A. Engenharia de Software e Sistemas de Informação. Brasport, 2ª edição. BIBLIOGRAFIA COMPLEMENTAR: WEBER,K.C. et all. Qualidade e produtividade em Software. Makron Books, 1999. ROCHA,A.R.C et all; Qualidade de Software. Editora Linarth, 1999. Anais do SBES - Simpósio Brasileiro de Engenharia de Software. SEI. SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2006. SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro. Guia Geral, versão 1.2. 2007. ABNT ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207 Tecnologia de informação - Processos de ciclo de vida de software. Rio de Janeiro, 1998. ISO/IEC - The International Organization for Standardization and The International Electrotechnical Commission, ISO/IEC TR 15504 Software Process Assessment. 1998. 15/26
Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com