Engenharia de Software

Engenharia de Software Introdução a Eng. de Software Engenharia de Requisitos • Prof. Me. Humberto Moura

Objetivos - Conhecer o Processo de engenharia de requisitos; - Aplicar Técnicas de elicitação de requisitos;

Projetos de Software Bem Sucedidos • Quando o cliente está satisfeito? • Pós-Graduação em Engenharia de Requisitos de Software • 11

Problema do Projetos de Software

Erro em Requisitos • 41% • Erro no Projeto Lógico • 28% • Fontes de erros em um projeto da US Air Force • 17 • Pós-Graduação em Engenharia de Requisitos de Software

Requisito • É uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os objetivos de negócio do cliente. • Pós-Graduação em Engenharia de Requisitos de Software • 24

Principais Causas de Fracasso em Projetos de Software • - Falta de método e técnicas para produzir os requisitos • - Falta de entendimento do negócio do cliente • Pós-Graduação em Engenharia de Requisitos de Software • 13

Custo Relativo para Reparar um Erro • Estudos realizados pela GTE, TRW e IBM, mediram e avaliaram os custos dos erros de requisitos ocorridos em várias fases do ciclo de vida de projetos de desenvolvimento de software. • Pós-Graduação em Engenharia de Requisitos de Software • 16

Sistema de Informação • A transformação de dados em informação é um processo ou uma série de atividades logicamente relacionadas, executadas para atingir um resultado definido. • 19 • Pós-Graduação em Engenharia de Requisitos de Software

SISTEMA DE INFORMAÇÃO – S.I. • 18 • Pós-Graduação em Engenharia de Requisitos de Software

SISTEMA DE INFORMAÇÃO – S.I. • 20 • Pós-Graduação em Engenharia de Requisitos de Software

Processo • “Grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes.” (Hammer e Champy, 1994) • 21 • Pós-Graduação em Engenharia de Requisitos de Software

Sistema de Informação • Análise de Negócio • 23

Cliente solicita: “Traga-me uma pedra” 2. Você, ao entregar a pedra, ouve: “Ok, mas, na verdade, o que eu realmente queria era uma pequena pedra de cor azul.” • Metáfora da Pedra

Metáfora da Pedra • Sistemas de software são, por sua natureza, intangíveis, abstratos, complexos e mutáveis. • O cliente inicia a articulação de requisitos vagos para o seu sistema “pedra”. • O cliente, frequentemente, acredita que pode detalhar melhor o que precisa ao longo do desenvolvimento. • Não há como criar, testar, desenvolver e manter um sistema “pedra” a custo zero e prazo indefinido.

Um cliente apresenta a seguinte necessidade: - Quero um programa que calcule a área de um retângulo. • Exemplo

O usuário deve informar o valor (em metros) de cada um dos lados, com precisão de duas casas decimais. A fórmula a ser utilizada é: L1 * L2 O valor calculado deve ser informado também com precisão de duas casas decimais, com truncamento simples. O cálculo deve ser disparado após comando do usuário. • A informação é suficiente?

Apresentar mensagem de erro quando, ao acionar o comando de cálculo, L1 e/ou L2 for(em) zero ou não for(em) especificado(s). Apresentar mensagem de erro se L1 = L2. Definir um limite máximo para as entradas L1 e L2. Incluir uma opção para limpar as entradas de dados. O programa deve operar em no sistema operacional Windows XP ou superior. Não há necessidade de impressão ou salvamento do resultado. O programa deve ser capaz de operar sem o uso do mouse. O resultado deve ser apresentado em até 1 segundo após o acionamento do comando de cálculo. Definir as mensagens. • E agora? • Melhorou ???

Relacionando Conceitos • Mapeamento • do • Processo • Identificação • do • Problema • Definição • dos • Objetivos • Análise do • Problema • Sistema de informações / Processos / Requisitos • Definição • dos • Requisitos • Proposta • de • Solução • Análise • do • Negócio • Produção e • Gerência • de • Requisitos • Viabilidade • Funcionalidades • e • Recursos • Engenharia • de • Requisitos • 37 • Pós-Graduação em Engenharia de Requisitos de Software

Identificação e Análise de Requisitos • Trabalha-se com o cliente • Entrevistas, simulações, documentos de referencia,... • Identificar as pessoas, os processos e as relações • Definir o limite do sistema • Registram-se os requisitos • Desenvolvedores e Cliente em consenso • Documento de Definição de Requisitos - DDR • Verificam-se os requisitos • Completos, corretos e consistentes • Validam-se os requisitos • Elaboração de Protótipos • Monitora e controla as mudanças nos requisitos • 43 • Pós-Graduação em Engenharia de Requisitos de Software

Documento de Requisitos • Domínio do • PROBLEMA • Requisitos do • Negócio • Necessidades • Recursos, • Perfil, • Prazo e Custo • (Requisitos • de Usuário) • Características • Domínio da • SOLUÇÃO • Requisitos de Software • ou de Sistema • Não Funcionais • Funcionais • Complementares • Regras de Negócio

Documento de Requisitos • Clientes • Projetistas • Definição dos Requisitos • Especificação dos Requisitos • Redefine os requisitos em termos técnicos; • Compreensível para o Projetista • Consenso entre Analista e Desenvolvedor • Envolve Modelagem • Lista do que o Cliente espera que o sistema faça; • Compreensível ao Cliente; • Consenso entre Cliente e Analista;

Não importa o método, deve-se manter um conjunto de documentos que registrem os requisitos Esse conjunto será utilizado durante todo o desenvolvimento e manutenção do sistema • Documentação dos Requisitos

Engenharia de Requisitos • "Criar e manter a documentação de requisitos do sistema."

Produção de Requisitos • Elicitação • Identificação da fonte de informação. Obtenção dos dados e fatos. Reunião com o cliente para entendimento do negocio. • Análise de Requisitos • Identificação dos requisitos a partir do processo de negócio. Acordo com o cliente do que se vai automatizar. • Documentação • Definição dos requisitos. Elaboração do documento de definição dos requisitos e regras de negocio. Documentação • Validação • Avaliar, junto ao cliente, se os requisitos realmente definem o sistema que o cliente deseja; Protótipo.

Rastreabilidade Relação entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefato Gerência de Mudanças Controla as solicitações de mudança do cliente Gerência de Configuração Controla as versões dos artefatos Gerência de Qualidade dos Requisitos Define o padrão de produção e verificação da qualidade dos requisitos. Capacita os analistas de requisitos e elabora o plano de gerencia de requisitos. • Gerência de Requisitos

Exercício - Estudo de Caso • Dividam-se em grupos de 5 alunos, onde 1 aluno é o cliente, e • para o sistema descrito a seguir escrever os requisitos funcionais, complementares, regras de negócio e não funcionais que forem identificados.

FIM • Inicio • Cadastra Usuario e Senha • Seleciona • Opção de Compra • Solicita • Usuário e Senha • Valida Usuário e Senha • Sistema Envia • e-mail • Cadastra • Endereço de Entrega • Busca Produto • Modifica • Produto • Confirma Compra • Fecha a Venda • Visualiza • Produto • Adiciona • Produto • Estudo de Caso • Possui • Cadastro? • Processo de Compra na WEB • Achou ? • Finaliza? • Não • Sim • Não • Sim • Sim • Não

Possíveis Respostas • Requisitos Funcionais • Sub-Processo Seleciona Produto • RF1 – O sistema deve buscar produto (rc01) • RF2 – O sistema deve adicionar produto (itens do carrinho) (rc02) • RF3 – O sistema deve visualizar produtos (itens do carrinho) (rc3) (rng1) (rng2) • RF4 – O sistema deve excluir produto (itens do carrinho) (rc01) • RF5 – O sistema deve alterar quantidade produto (itens do carrinho) (rc02) • RF6 – O sistema deve finalizar pedido (fechar carrinho) (rc04) (rgn3) (rgn4) (rgn5) (rgn6)

Possíveis Respostas • Requisitos Funcionais • Sub-Processo Seleciona Realiza Compra • RF7 – O sistema deve identificar cliente (rc5) • RF8 – O sistema deve cadastrar cliente (rc6) • RF9 – O sistema deve cadastrar endereço de entrega (rc7) • RF10 – O sistema deve permitir ao cliente selecionar opção de pagamento (rc08) • RF11 – O sistema deve confirmar a compra (rc9) (rng7) • RF12 – O sistema deve enviar e-mail de status (rc10)

Estudo de Caso • Requisitos Complementares • Sub-Processo Seleciona Produto • RC1 – o sistema deve permitir selecionar nome do produto (RF1) (RF4) • RC2 – o sistema deve permitir selecionar nome e quantidade (RF2) (RF5) • RC3 – o sistema deve exibir produto, quantidade, valor e total ao visualizar produto (carrinho) (RF3) • RC4 – o sistema deve permitir registrar nome, data e hora ao finalizar o pedido (RF6)

Estudo de Caso • Requisitos Complementares • Sub-Processo Seleciona Realiza Compra • RC5 – o sistema deve identificar o cliente por usuário e senha ao finalizar o pedido (RF7) • RC6 – o sistema deve cadastrar usuário e senha (RF8) • RC7 – o sistema deve cadastrar endereço, bairro, cidade e cep (RF9) • RC8 – o sistema deve exibir as seguintes opções de pagamento: cartão de crédito e boleto bancário (RF10) • RC9 – o sistema deve registrar nome, data, hora, produto e quantidade ao confirmar o pedido (RF11) • RC10 – o sistema deve informar o status da compra (aguardando confirmação do cartão de credito ou do pagamento do boleto) ao finalizar a compra (RF12)

Estudo de Caso • Regras de Negócio • RNG1 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir alteração de quantidade de itens(RF3) • RNG2 – quando o cliente visualizar os produtos (carrinho) o sistema deve permitir exclusão de itens(RF3) • RNG3 – quando o cliente finalizar o pedido o sistema deve identificar cliente (RF7) • RNG4 – quando o cliente finalizar o pedido e o cliente não for cadastrado o sistema deve permitir cadastrar cliente(RF8) • RNG5 – quando o cliente finalizar o pedido o sistema deve cadastrar endereço de entrega(RF9) • RNG6 – quando o cliente finalizar o pedido o sistema deve permitir selecionar tipo de pagamento(RF10) • RNG7 – quando o cliente confirmar a compra o sistema deve enviar e-mail informando status da compra(RF12)

1. Confiablidade O sistema deve garantir que a atualização de dados será feita de forma atômica e imediata, sempre com registro histórico; O sistema deve realizar backups diariamente após a 00:00 hrs; 2. Eficiência O sistema deve responder a qualquer pesquisa, inclusão, alteração e exclusão em tempo inferior a 3 (três) segundos; O sistema deve garantir que as atualizações dinâmicas de informação única não devem exceder 1 (um) segundo; • Requisitos Não Funcionais

3. Portabilidade O sistema deve ser executado em em microcomputadores de arquitetura IBM PC, com processadores Intel P4 2.5Ghz com 512Mb de memória RAM e HD de 40Gb com sistema operacional Windows XP; O sistema deve ser portável para GNU/Linux, com ambiente Desktop GNOME, em máquina de mesma configuração; 4. Usabilidade O sistema deve focar em eficiência, fornecendo teclas de atalho para todas as ações mais importantes; O sistema deve seguir as Diretrizes de Interface Humana do projeto GNOME: http://developer.gnome.org/projects/gup/hig/; • Requisitos Não Funcionais

Bibliografia PRESSMAN, Roger S. Engenharia de Software. Porto Alegre: McGraw-Hill, 2011. SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson Education - Br, 2011. SWEBOK - Guide to the Software Engineering Body of Knowledge (www.swebok.org) WIEGERS, Karl E. More About Software Requirements. 1a. Ed. –Redmond, Washington: Microsoft Press, 2006

Engenharia de Software