Upload
internet
View
106
Download
1
Embed Size (px)
Citation preview
Ricardo Ajax Dias Kosloski, MSC, [email protected]
Pós-Graduação em Engenharia de Requisitos de
Software
Engenharia deRequisitos
Apresentações
2 Pós-Graduação em Engenharia de Requisitos de Software
Ricardo Ajax Dias kosloskiEngo. Eletricista - UnBAnalista de Sistemas - UcBPos-graduação em Enga. Software (UcB)MSC – MGCTI (UcB)
10 anos como analista de Sistemas6 Anos em Gerência de Projetos9 anos em Métricas e Qualidade de Software
Certificado CFPS desde 2003
Ricardo Ajax Dias kosloskiEngo. Eletricista - UnBAnalista de Sistemas - UcBPos-graduação em Enga. Software (UcB)MSC – MGCTI (UcB)
10 anos como analista de Sistemas6 Anos em Gerência de Projetos9 anos em Métricas e Qualidade de Software
Certificado CFPS desde 2003
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
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.
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
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)
• WIEGERS, Karl E. More About Software Requirements. 1a. Ed. –Redmond, Washington: Microsoft Press, 2006
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 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
• 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 Software9
1. Motivação2. Conceituação 3. Mais sobre Requisitos...
Agenda da Aula 01
Pós-Graduação em Engenharia de Requisitos de Software10
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
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).
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
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.
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)
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.
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
Conceitos
Pós-Graduação em Engenharia de Requisitos de Software
SISTEMA DE INFORMAÇÃO – S.I.
18
Conceitos
Pós-Graduação em Engenharia de Requisitos de Software19
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.
SISTEMA DE INFORMAÇÃO – S.I.
Conceitos
Pós-Graduação em Engenharia de Requisitos de Software20
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 Software21
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 Software22
Análise de Negócio
Conceitos
SISTEMA DE INFORMAÇÃO – S.I.
23
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
• 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
• 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
• 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
• 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
• Supor que um Cliente apresente a seguinte necessidade:
Um programa que calcule a área de um retângulo.
Exemplificando
Conceitos
• 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
• 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
Evolução do ProblemaEvolução do Problema
• 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
• 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
Evolução do Problema
• 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
Mapeamentodo
Processo
Identificação do
Problema
Análise doProblema
Análise do
Negócio
Viabilidade
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Funcionalidadese
Recursos
Definiçãodos
Requisitos
Engenhariade
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
Pós-Graduação em Engenharia de Requisitos de Software37
Entendemos o negócio do
Cliente?
Mapeamentodo
Processo
Identificaçãodo
Problema
Análise doProblema
Análise do
Negócio
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Definiçãodos
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
Pós-Graduação em Engenharia de Requisitos de Software38
Conseguimos entender o
problema do Cliente?
Mapeamentodo
Processo
Identificaçãodo
Problema
Análise doProblema
Análise do
Negócio
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Definiçãodos
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
Pós-Graduação em Engenharia de Requisitos de Software39
Definimos o Problema a
ser automatizad
o?
Mapeamentodo
Processo
Identificaçãodo
Problema
Análise doProblema
Análise do
Negócio
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Definiçãodos
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
Pós-Graduação em Engenharia de Requisitos de Software40
Conseguimos identificar as necessidades do Cliente?
Mapeamentodo
Processo
Identificaçãodo
Problema
Análise doProblema
Análise do
Negócio
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Definiçãodos
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
41 Pós-Graduação em Engenharia de Requisitos de Software
Conseguimos definir os requisitos
que o cliente esperava?
Mapeamentodo
Processo
Identificaçãodo
Problema
Análise doProblema
Análise do
Negócio
Produção eGerência
deRequisitos
Definição dos
Objetivos
Proposta de
Solução
Definiçãodos
Requisitos
Sistema de informações / Processos / Requisitos
Relacionando Conceitos
42 Pós-Graduação em Engenharia de Requisitos de Software
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 Software43
Documento de Requisitos
Documento de Requisitos
Necessidades
Características
Requisitos de Softwareou de Sistema
Domínio doPROBLEMA
Domínio da
SOLUÇÃO
Requisitos doNegócio
Funcionais Não Funcionais
Recursos,Perfil,
Prazo e Custo(Requisitos de Usuário)
Documento de Requisitos
Regras de NegócioComplementares
• Dois tipos de DOCUMENTO de REQUISITOS
Clientes Projetistas
Especificaçãodos Requisitos
Definiçãodos 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
• 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
• 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
• 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
Engenharia de Requisitos
• 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
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
•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
• Os 4 subprocessos da Gerência de Requisitos:
– RastreabilidadeRelação entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefato
– Gerência de MudançasControla as solicitações de mudança do cliente
– Gerência de ConfiguraçãoControla as versões dos artefatos
– Gerência de Qualidade dos RequisitosDefine 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
• 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
• 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
• 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
• 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
Processo XR
eXtreme Requirements
(Eduardo Castro, Direitos Reservados)
Processo XR
eXtreme Requirements
(Eduardo Castro, Direitos Reservados)
Próxima Aula
60
Análise do Negócio
Definição dos Requisitos
Disciplinas
FasesAnálise ValidaçãoElicitação Documentação
Proposta de Solução
Prototipação
Teste
Gerência de Requisitos
Disciplinas de ApoioGerência de Projeto
Métrica de Software
Administração de Dados
Processo eXtreme Requirements®
Eduardo José Ribeiro de Castro
Estudo de Caso
(Estudar para a próxima aula)
Estudo de Caso
(Estudar para a próxima aula)
Perguntas?
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
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
Busca ProdutoBusca Produto
AdicionaProdutoAdicionaProduto
Achou ? Achou ?
PossuiCadastro?PossuiCadastro?
SolicitaUsuário e Senha
SolicitaUsuário e Senha
FIMFIM
Cadastra Usuario e Senha
Cadastra Usuario e Senha
CadastraEndereço de Entrega
CadastraEndereço de Entrega
Sim
Não
Finaliza? Finaliza?
Sim
Não
Não
SimSelecionaOpção de Compra
SelecionaOpção de Compra
Confirma CompraConfirma Compra
Sistema Envia e-mail
Sistema Envia e-mail
Valida Usuário e Senha
Valida Usuário e Senha
Fecha a VendaFecha a Venda
VisualizaProdutoVisualizaProduto
ModificaProdutoModificaProduto
InicioInicio Processo de Compra na WEB
Estudo de Caso
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
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
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
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
RastreabilidadeRastreabilidade
Rastreabilidade
Requisitos Funcionais x Requisitos Complementares
Req.Complementar
Req. FuncionaisRC01 RC02 RC03 RC04 RC05 RC06 RC07 RC08 RC09 RC10
RF01 xRF02 xRF03 xRF04 xRF05 xRF06 xRF07 xRF08 xRF09 xRF10 xRF11 xRF12 x
Estudo de Caso
Rastreabilidade
Requisitos Funcionais x Regras de Negocio
Regras de Neg.
Req. FuncionaisRNG01 RNG02 RNG03 RNG04 RNG05 RNG06 RNG07
RF03x x
RF07x
RF08x
RF09x
RF10x
RF12x
Estudo de Caso
Modelagem de Requisitos
Analise O.O.
Modelagem de Requisitos
Analise O.O.
– 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
Estudo de Caso
Modelagem de Requisitos
Analise Estruturada
Modelagem de Requisitos
Analise Estruturada
– 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
Estudo de Caso