Ricardo Ajax Dias Kosloski, MSC, CFPS Pós-Graduação em Engenharia de Requisitos de Software Engenharia de Requisitos.

Apresentação em tema: "Ricardo Ajax Dias Kosloski, MSC, CFPS Pós-Graduação em Engenharia de Requisitos de Software Engenharia de Requisitos."— Transcrição da apresentação:

1 Ricardo Ajax Dias Kosloski, MSC, CFPS rikosdf@gmail.com Pós-Graduação em Engenharia de Requisitos de Software Engenharia de Requisitos

2 Apresentações 2 Pós-Graduação em Engenharia de Requisitos de Software Ricardo Ajax Dias kosloski Eng o. Eletricista - UnB Analista de Sistemas - UcB Pos-graduação em Eng a. Software (UcB) MSC – MGCTI (UcB) 10 anos como analista de Sistemas 6 Anos em Gerência de Projetos 9 anos em Métricas e Qualidade de Software Certificado CFPS desde 2003

3 Apresentações 3 Pós-Graduação em Engenharia de Requisitos de Software Pós-graduandos Nome Formação básica Atuação Expectativa quanto ao curso e à disciplina

4 Apresentações 4 Pós-Graduação em Engenharia de Requisitos de Software Plano de Ensino 05 encontros (20 h.a) Apresentação do Professor, da disciplina e da metodologia de trabalho; revisão de conceitos (sistemas de informação, Engenharia de Software e Requisitos – conceitos/ tipos); Engenharia de Requisitos e Processos em Engenharia de Requisitos. Processo de produção de Requisitos; Elicitação de requisitos; Analise de requisitos; Documentação dos Requisitos; Validação dos Requisitos Processo de produção de Requisitos; Estudo de Caso; Exercício Processo de Gerencia de Requisitos; Gerência de Mudanças; Gerência de Configuração e Mudança; Rastreabilidade de requisitos; Gerência da Qualidade do Requisito Apresentação de trabalhos finais, avaliações.

5 Apresentações 5 Pós-Graduação em Engenharia de Requisitos de Software Plano de Ensino Metodologia de Ensino Aulas expositivas com recursos de projeção Trabalho para avaliação Leitura e discussão de artigos e trabalhos técnicos da área

6 Bibliografia 6 Pós-Graduação em Engenharia de Requisitos de Software PFLEEGER, Shari Lawrence. Engenharia de Software – Teoria e Prática. 2ª. Ed. – São Paulo: Pearson – Prentice Hall, 2007 ; PRESSMAN, Roger. S. Engenharia de software: um enfoque prático. 3. ed. São Paulo: Makron Books, 1995. SOMMERVILLE, Ian.Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003 SWEBOK - Guide to the Software Engineering Body of Knowledge (www.swebok.org)www.swebok.org WIEGERS, Karl E. More About Software Requirements. 1a. Ed. – Redmond, Washington: Microsoft Press, 2006

7 Avaliação 7 Pós-Graduação em Engenharia de Requisitos de Software 01 Trabalho individual – a partir da PDS 01 Prova de conceitos Participação...

8 8 Pós-Graduação em Engenharia de Requisitos de Software Horário – Das 19:00 às 22:30 Intervalos – Das 20:45 às 21:00 Perguntas – A qualquer momento Planejamento

9 Objetivos do curso Revisão dos conceitos gerais sobre Sistemas de Informação, Processos e Engenharia de Software. Conceitos gerais sobre Engenharia de Requisitos e seus processos de produção e gerencia de requisitos. Processo eXtreme Requirements para documentação de requisitos; Tipos de Requisitos e Estudos de Caso. Objetivos Pós-Graduação em Engenharia de Requisitos de Software 9

10 1.Motivação 2.Conceituação 3.Mais sobre Requisitos... Agenda da Aula 01 Pós-Graduação em Engenharia de Requisitos de Software 10

11 Motivação 11 Um projeto bem sucedido é aquele para o qual se aplicam os seguintes aspectos : –Cliente/usuário satisfeito; –Auxiliou positivamente na obtenção da meta do negócio; –Executou o escopo exatamente como previsto e o software está sendo utilizado como previsto; –Atendeu às especificações técnicas de qualidade e desempenho; –Atendeu às restrições de prazo e custo. Resultado: Pouquíssimos projetos de T.I. seriam classificados como bem sucedidos. Pós-Graduação em Engenharia de Requisitos de Software

12 Motivação 12 Pós-Graduação em Engenharia de Requisitos de Software Leffingwell ressalta que 40% a 60% de todos os problemas encontrados em um projeto são causados por falhas no processo de requisitos (ausência ou à não utilização de um processo de definição de requisitos adequado). As consequências da falta de um processo de requisitos eficaz têm sido a produção de softwares que não refletem as necessidades reais dos clientes. Como os requisitos constituem a base para o desenvolvimento do software, então, requisitos de má qualidade geram software com qualidade inadequada. Segundo Finkelstein, a análise final da qualidade de um software é determinada pelo atendimento aos requisitos dos stakeholders (envolvidos).

13 Motivação 13 Pós-Graduação em Engenharia de Requisitos de Software Principais causas de fracasso Poucos analistas fazem uso de técnicas no momento de elicitar e analisar os requisitos de um sistema. Não é incomum encontrarmos desenvolvedores que definem, eles próprios, os requisitos dos sistemas e depois agem como se não soubessem o porquê do cliente não homologar tal aplicação. Falhamos por não termos método e técnicas para produzir os requisitos Desenvolvedores, de uma forma geral, têm uma visão simplista do processo de software. É comum que projetos sejam iniciados e continuados mesmo com falhas nas informações dos usuários É necessário obter o conhecimento do negócio e das necessidades do usuário Falhamos quando não entendemos o negócio do cliente

14 Motivação 14 Pós-Graduação em Engenharia de Requisitos de Software Principais causas de fracasso Falhamos quando perdemos o controle do processo, permitindo que cliente e gerentes interfiram diretamente na equipe e no processo de desenvolvimento do sistema.

15 Motivação 15 Pós-Graduação em Engenharia de Requisitos de Software Por que requisitos são importantes? Qualidade de Software: “Conformidade a requisitos funcionais e de desempenho, explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo o software profissionalmente desenvolvido.” (Pressman) Uma compreensão completa do problema e a definição dos requisitos do software e sua especificação minuciosa é fundamental para o processo de desenvolvimento obter um software com alta qualidade. Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor. Falha na definição dos requisitos  Defeitos do software Principal defeito: Não atender as expectativas de negócios do usuário (cliente)

16 Motivação 16 Pós-Graduação em Engenharia de Requisitos de Software O alto custo dos erros de requisitos 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. Se uma unidade de custo 1 é associada ao esforço requerido para detectar e reparar um erro durante a fase de codificação, –o custo para detectar e reparar um erro durante a fase de requisitos está entre 5 a 10 vezes menor. Por outro lado, o custo para detectar e reparar um erro durante a fase de manutenção é 20 vezes maior.

17 Motivação Pós-Graduação em Engenharia de Requisitos de Software O alto custo dos erros de requisitos Em um estudo realizado por Sheldon, em um projeto da US Air Force, os erros foram classificados pela origem. Descobriu-se que os erros de requisitos totalizavam 41% dos erros descobertos, enquanto que erros de projeto lógico contabilizavam apenas 28% do total de erros encontrados. Fontes de erros em um projeto da US Air Force 17

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

19 Conceitos Pós-Graduação em Engenharia de Requisitos de Software 19 Sistemas 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. O processo de definição das relações entre atividades requer conhecimento. Conhecimento são regras, diretrizes e procedimentos usados para selecionar, organizar e manipular dados, com a finalidade de torná-los úteis para uma tarefa específica.

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

21 Processo “Conjunto de recursos e atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas).” (ISO, 1990) “Conjunto de atividades inter-relacionadas, que transformam entradas em saídas.” (Pfleeger, 2002) “Um processo é um 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) Conceitos Pós-Graduação em Engenharia de Requisitos de Software 21

22 Processo Todo trabalho importante realizado nas empresas faz parte de algum processo (Graham e LeBaron,1994). Conceitos Pós-Graduação em Engenharia de Requisitos de Software 22

23 Análise de Negócio Conceitos SISTEMA DE INFORMAÇÃO – S.I. 23

24 24 Pós-Graduação em Engenharia de Requisitos de Software De forma genérica: É 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 Mas... O que é um requisito? Conceitos

25 A identificação dos requisitos de um sistema pode ser exemplificado pela metáfora do “problema da pedra”: 1.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.” Exemplificando Conceitos

26 A identificação dos requisitos de um sistema pode ser exemplificado pela metáfora do “problema da pedra”: 3. Você entrega a pedrinha azul, mas o cliente observa: “Ora, mas a pedra que eu queria é esférica !!!” Exemplificando Conceitos

27 Resultado: –cliente e desenvolvedor frustrados Problemas adicionais: –No mundo real, há o envolvimento de mais pessoas –Não há tempo para trazer várias “pedras” até acertar Exemplificando Conceitos

28 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. Exemplificando Conceitos

29 Supor que um Cliente apresente a seguinte necessidade: Um programa que calcule a área de um retângulo. Exemplificando Conceitos

30 Agora... Um programa que calcule a área de um retângulo. 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. Suficiente ??? Exemplificando Conceitos

31 E mais... Um programa que calcule a área de um retângulo. 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. Melhorou ??? O Maravilhoso Programa de Cálculo de Áreas de Retângulos Exemplificando Conceitos

32 Evolução do Problema

33 Esse problema é tão antigo e conhecido na área de desenvolvimento de software, que na década de 70 alguém teve a idéia de fazer o seguinte desenho ilustrando a situação. Evolução do Problema

34 Alguém que esteja começando uma carreira de analista ou desenvolvedor de software poderá imaginar que um problema tão antigo já foi solucionado, ou, que pelo menos, o seu impacto nos projetos de software tenha sido minimizado. Que grande engano! O problema é ainda tão crítico, que o desenho foi revisto e adequado aos nossos dias. Evolução do Problema

35

36 O que é um REQUISITO? 1.Uma capacidade do software necessária ao usuário para resolver um problema ou atingir um objetivo. 2.Uma capacidade do software que deve existir no sistema ou em algum componente para satisfazer um contrato, um padrão, uma especificação ou outra documentação formalmente imposta. (Dorfman e Thayer, 1990) Conceitos

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

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

39 Conseguimos entender o problema do Cliente? Mapeamento do Processo Identificação do Problema Análise do Problema Análise do Negócio Produção e Gerência de Requisitos Definição dos Objetivos Proposta de Solução Definição dos Requisitos Sistema de informações / Processos / Requisitos Relacionando Conceitos Pós-Graduação em Engenharia de Requisitos de Software 39

40 Definimos o Problema a ser automatizado? Mapeamento do Processo Identificação do Problema Análise do Problema Análise do Negócio Produção e Gerência de Requisitos Definição dos Objetivos Proposta de Solução Definição dos Requisitos Sistema de informações / Processos / Requisitos Relacionando Conceitos Pós-Graduação em Engenharia de Requisitos de Software 40

41 Conseguimos identificar as necessidades do Cliente? Mapeamento do Processo Identificação do Problema Análise do Problema Análise do Negócio Produção e Gerência de Requisitos Definição dos Objetivos Proposta de Solução Definição dos Requisitos Sistema de informações / Processos / Requisitos Relacionando Conceitos 41 Pós-Graduação em Engenharia de Requisitos de Software

42 Conseguimos definir os requisitos que o cliente esperava? Mapeamento do Processo Identificação do Problema Análise do Problema Análise do Negócio Produção e Gerência de Requisitos Definição dos Objetivos Proposta de Solução Definição dos Requisitos Sistema de informações / Processos / Requisitos Relacionando Conceitos 42 Pós-Graduação em Engenharia de Requisitos de Software

43 Identificar e analisar 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 Relacionando Conceitos Pós-Graduação em Engenharia de Requisitos de Software 43

44 Documento de Requisitos

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

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

47 Documentação de Requisitos –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 Documento de Requisitos

48 A importância do processo de requisitos fez por definir uma outra “engenharia” dentro da Engenharia de Software: –Engenharia de Requisitos Objetivo: –criar e manter a documentação de requisitos do sistema. Engenharia de Requisitos

49 A ER é uma sub-área da Engenharia de Software que estuda o processo de produção e gerência dos requisitos que o software deverá atender. O objetivo da ER é fornecer métodos, técnicas e ferramentas que forneçam suporte adequado às tarefas de produção (elicitação, análise, documentação e modelagem) e gerência dos requisitos do sistema. Foi estabelecida como disciplina independente em 1993, quando da criação do IEEE International Symposyum on Requirements Engineering (RE’93). A área tem crescido desde então. Para isso estabelece um processo no qual o que deve ser feito é elicitado, analisado, documentado e modelado. Engenharia de Requisitos

50

51 Os 4 subprocessos da 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. Engenharia de Requisitos

52 Porém... “Caminhar sobre a água e desenvolver software a partir de uma especificação de requisitos é fácil se ambos estão congelados” Edward V. Berard Engenharia de Requisitos

53 Requisitos são por natureza voláteis. Diversos fatores contribuem para sua instabilidade ao longo do tempo. Mudanças de legislação, erros incorridos no processo de requisitos, entre outros Tais alterações precisam ser conduzidas de forma ordenada para que não se perca controle sobre o prazo e o custo do desenvolvimento Denominamos a atividade de administrar os requisitos ao longo do tempo de gerenciamento de requisitos Engenharia de Requisitos

54 Os 4 subprocessos da Gerência de Requisitos: –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. Engenharia de Requisitos

55 A tendência natural das organizações que trabalham sem um processo de ER tem sido identificar os requisitos rapidamente de maneira informal e iniciar a codificação. Este é o processo “codifica-remenda” até a produção de uma versão com qualidade adequada ou o cancelamento do projeto. Estes projetos freqüentemente estouram o prazo e o orçamento. –Note que o esforço e o custo do retrabalho são maiores do que os investimentos em ER, buscando desenvolver o projeto certo da primeira vez. Assim, torna-se importante desenvolver métodos atrativos para implantação das atividades da ER que motivem a indústria a investir em um processo completo de ER. Engenharia de Requisitos

56 A indústria de software vem demonstrando crescente interesse na engenharia de requisitos, isto é, entender o que se deseja construir antes de começar a fazê-lo (Ex.: MPS.BR). A visão atual é que o tempo utilizado no entendimento do problema é um excelente investimento. Os requisitos de software são a base a partir da qual a qualidade é medida (Ex.: APF) Desta forma, a falta de conformidade aos requisitos significa falta de qualidade. Engenharia de Requisitos

57 O modelo de avaliação de maturidade do processo de desenvolvimento CMMI-SW (Capability Maturity Model Integration-SW) considera o gerenciamento de requisitos como sendo uma das primeiras etapas para alcançar a maturidade organizacional. E para haver o gerenciamento é preciso que o processo de produção de requisitos esteja implantado na empresa. Engenharia de Requisitos

58 Este processo deve lidar com diferentes pontos de vista, e usar uma combinação de métodos, ferramentas e pessoal. Tem início junto aos clientes durante a fase de elicitação ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software. O produto desse processo é um documento chamado de documento requisitos (DR) e um modelo (representado utilizando Análise Estruturada ou Orientada a Objetos) do Sistema de Informação a partir do documento de requisitos. Engenharia de Requisitos

59 59 Processo XR  eXtreme Requirements  (Eduardo Castro, Direitos Reservados) Processo XR  eXtreme Requirements  (Eduardo Castro, Direitos Reservados) Próxima Aula

60 60 Análise do Negócio Definição dos Requisitos Disciplinas Fases AnáliseValidaçãoElicitaçãoDocumentação Proposta de Solução Prototipação Teste Gerência de Requisitos Disciplinas de Apoio Gerência de Projeto Métrica de Software Administração de Dados Processo eXtreme Requirements ® Eduardo José Ribeiro de Castro

61 Estudo de Caso (Estudar para a próxima aula) Estudo de Caso (Estudar para a próxima aula)

62 Perguntas?

63 Para o sistema descrito a seguir (Compras NET), escrever os requisitos funcionais, complementares, regras de negócio e não funcionais que forem identificados. Estudo de Caso

64 Compras NET O cliente navega pelo site e adiciona itens desejados ao carrinho de compras. Se não encontrar o produto desejado, pode usar a opção de busca. Durante sua navegação no site, o cliente pode ver o conteúdo de seu carrinho de compras, alterando quantidades ou excluindo itens. Quando o cliente finalizar a compra, ele deve se identificar com seu login/senha. Caso não seja ainda cadastrado, deverá fazê-lo antes de prosseguir. Em seguida, informa o endereço de entrega daquela compra e detalha a opção de pagamentos (dados do cartão de crédito ou para pagamento por boleto bancário). Confirmada a compra, o sistema fecha a venda e envia um e-mail informando ao cliente o status da compra (aguardando confirmação do cartão de credito ou do pagamento do boleto). Estudo de Caso

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

66 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) 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

67 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) 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

68 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) Estudo de Caso

69 Requisitos não funcionais 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; 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/; Estudo de Caso

70 Rastreabilidade

71 Requisitos Funcionais x Requisitos Complementares Req.Complementar Req. Funcionais RC01RC02RC03RC04RC05RC06RC07RC08RC09RC10 RF01 x RF02 x RF03 x RF04 x RF05 x RF06 x RF07 x RF08 x RF09 x RF10 x RF11 x RF12 x Estudo de Caso

72 Rastreabilidade Requisitos Funcionais x Regras de Negocio Regras de Neg. Req. Funcionais RNG01RNG02RNG03RNG04RNG05RNG06RNG07 RF03 xx RF07 x RF08 x RF09 x RF10 x RF12 x Estudo de Caso

73 Modelagem de Requisitos Analise O.O. Modelagem de Requisitos Analise O.O.

74 –Os requisitos funcionais e regras de negócio são avaliadas de forma a elaborar o diagrama de caso de uso –Os casos de uso podem modelar 1 ou um conjunto de requisitos funcionais que sejam necessários a um determinado ator realizar sua tarefa. –Os atores são identificados dos elementos envolvidos no processo e definidos no Documento de Definição de Requisitos - DDR Estudo de Caso

75

76 Modelagem de Requisitos Analise Estruturada Modelagem de Requisitos Analise Estruturada

77 –Os requisitos funcionais, requisitos complementares e regras de negócio são avaliadas de forma a elaborar o Diagrama de Contexto - DC e posteriormente o Diagrama de Fluxo de Dados - DFD –Os fluxos de dados se relacionam diretamente aos Requisitos Funcionais - RF, tendo em vista que cada RF obrigatoriamente possui Requisitos Complementar que representa os dados. –As entidades são identificadas dos elementos envolvidos no processo e definidos no Documento de Definição de Requisitos - DDR Estudo de Caso

78