Pós-Graduação em
Engenharia de Requisitos de Software
Engenharia de
Requisitos
Ricardo Ajax Dias Kosloski, MSC, CFPS
[email protected]
Apresentações
Ricardo Ajax Dias kosloski
Engo. Eletricista - UnB
Analista de Sistemas - UcB
Pos-graduação em Enga. 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
2
Pós-Graduação em Engenharia de Requisitos de Software
Apresentações
Pós-graduandos
•
•
•
•
3
Nome
Formação básica
Atuação
Expectativa quanto ao curso e à disciplina
Pós-Graduação em Engenharia de Requisitos de Software
Apresentações
Plano de Ensino
05 encontros (20 h.a)
4
•
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.
Pós-Graduação em Engenharia de Requisitos de Software
Apresentações
Plano de Ensino
Metodologia de Ensino
•
•
•
5
Aulas expositivas com recursos de projeção
Trabalho para avaliação
Leitura e discussão de artigos e trabalhos técnicos da área
Pós-Graduação em Engenharia de Requisitos de Software
Bibliografia
•
•
•
•
•
6
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
Pós-Graduação em Engenharia de Requisitos de Software
Avaliação
• 01 Trabalho individual – a partir da PDS
• 01 Prova de conceitos
• Participação...
7
Pós-Graduação em Engenharia de Requisitos de Software
Planejamento
• Horário
– Das 19:00 às 22:30
• Intervalos
– Das 20:45 às 21:00
• Perguntas
– A qualquer momento
8
Pós-Graduação em Engenharia de Requisitos de Software
Objetivos
• 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.
9
Pós-Graduação em Engenharia de Requisitos de Software
Agenda da Aula 01
1. Motivação
2. Conceituação
3. Mais sobre Requisitos...
10
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
• 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.
11
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
• 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).
12
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
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
13
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
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.
14
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
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)
15
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
O alto custo dos erros de requisitos
16
•
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.
Pós-Graduação em Engenharia de Requisitos de Software
Motivação
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
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
SISTEMA DE INFORMAÇÃO – S.I.
PROCESSAMENTO
ENTRADA
SAÍDA
ARMAZENA
FEEDBACK
18
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
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.
19
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
SISTEMA DE INFORMAÇÃO – S.I.
PROCESSO
DADOS
20
INFORMAÇÃO
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
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)
21
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
Processo
• Todo trabalho importante realizado nas empresas faz parte de algum
processo (Graham e LeBaron,1994).
22
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
Análise de Negócio
SISTEMA DE INFORMAÇÃO – S.I.
PROCESSO
DADOS
Mapeamento do
Processo
Identificação do
Problema
Análise do
Problema
23
Proposta de
Solução
INFORMAÇÃO
Conceitos
Mas... O que é um requisito?
• 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
24
Pós-Graduação em Engenharia de Requisitos de Software
Conceitos
Exemplificando
• 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.”
Conceitos
Exemplificando
• 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 !!!”
Conceitos
Exemplificando
• 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
Conceitos
Exemplificando
• 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.
Conceitos
Exemplificando
• Supor que um Cliente apresente a seguinte
necessidade:
Um programa que calcule a área de um retângulo.
Conceitos
Exemplificando
• 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 ???
Conceitos
Exemplificando
O Maravilhoso Programa de
Cálculo de Áreas de
Retângulos
• 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 ???
Evolução do Problema
Evoluçã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
Conceitos
•
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)
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Viabilidade
37
Análise do
Problema
Definição
dos
Requisitos
Definição
dos
Objetivos
Produção e
Gerência
de
Requisitos
Funcionalidades
e
Recursos
Engenharia
de
Requisitos
Pós-Graduação em Engenharia de Requisitos de Software
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Análise do
Problema
Definição
dos
Objetivos
Entendemos o
negócio do
Cliente?
38
Pós-Graduação em Engenharia de Requisitos de Software
Definição
dos
Requisitos
Produção e
Gerência
de
Requisitos
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Análise do
Problema
Definição
dos
Objetivos
Conseguimos entender o
problema do Cliente?
39
Pós-Graduação em Engenharia de Requisitos de Software
Definição
dos
Requisitos
Produção e
Gerência
de
Requisitos
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Análise do
Problema
Definição
dos
Objetivos
Definimos o
Problema a ser
automatizado?
40
Pós-Graduação em Engenharia de Requisitos de Software
Definição
dos
Requisitos
Produção e
Gerência
de
Requisitos
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Análise do
Problema
Definição
dos
Objetivos
Conseguimos
identificar as
necessidades do
Cliente?
41
Pós-Graduação em Engenharia de Requisitos de Software
Definição
dos
Requisitos
Produção e
Gerência
de
Requisitos
Relacionando Conceitos
Sistema de informações / Processos / Requisitos
Proposta
de
Solução
Análise
do
Negócio
Mapeamento
do
Processo
Identificação
do
Problema
Análise do
Problema
Definição
dos
Objetivos
Definição
dos
Requisitos
Produção e
Gerência
de
Requisitos
Conseguimos
definir os
requisitos que o
cliente esperava?
42
Pós-Graduação em Engenharia de Requisitos de Software
Relacionando Conceitos
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
43
Pós-Graduação em Engenharia de Requisitos de Software
Documento de Requisitos
Documento de Requisitos
Domínio do
PROBLEMA
Necessidades
Características
Domínio
da
SOLUÇÃO
Requisitos do
Negócio
Recursos,
Perfil,
Prazo e Custo
(Requisitos
de Usuário)
Requisitos de Software
ou de Sistema
Funcionais
Não Funcionais
Complementares Regras de Negócio
Documento de Requisitos
• Dois tipos de DOCUMENTO de REQUISITOS
Clientes
Definição
dos Requisitos
•Lista do que o Cliente espera que o
sistema faça;
•Compreensível ao Cliente;
•Consenso entre Cliente e Analista;
Projetistas
Especificação
dos Requisitos
•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
Engenharia 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:
– 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
• 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.
Próxima Aula
Processo XR
eXtreme Requirements
(Eduardo Castro, Direitos Reservados)
59
Processo eXtreme Requirements®
Eduardo José Ribeiro de Castro
Fases
Disciplinas
Elicitação
Análise
Documentação Validação
Análise do
Negócio
Proposta de
Solução
Definição
dos
Requisitos
Prototipação
Teste
Gerência de
Requisitos
Disciplinas de Apoio
Gerência de
Projeto
60
Administração
de Dados
Métrica de
Software
Estudo de Caso
(Estudar para a próxima aula)
Perguntas?
Estudo de Caso
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
Inicio
Processo de Compra na WEB
Não
Busca
Produto
Sim
Achou ?
Adiciona
Produto
Visualiza
Produto
Modifica
Produto
Não
Seleciona
Opção de
Compra
Cadastra
Endereço
de Entrega
Sim
Valida
Usuário e
Senha
Sim
Possui
Cadastro?
Não
Confirma
Compra
Fecha a
Venda
Finaliza?
Sistema
Envia
e-mail
FIM
Cadastra
Usuario e
Senha
Solicita
Usuário e
Senha
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/;
Rastreabilidade
Estudo de Caso
Rastreabilidade
Requisitos Funcionais x Requisitos Complementares
Req.Complementar
RC01
Req. Funcionais
RF01
RC02
RF06
RF07
RF08
RF09
RF10
RF11
RF12
RC05
RC06
RC07
RC08
RC09
RC10
x
RF03
RF05
RC04
x
RF02
RF04
RC03
x
x
x
x
x
x
x
x
x
x
Estudo de Caso
Rastreabilidade
Requisitos Funcionais x Regras de Negocio
Regras de Neg.
RNG01
RNG02
x
x
RNG03
RNG04
RNG05
RNG06
RNG07
Req. Funcionais
RF03
RF07
RF08
RF09
RF10
RF12
x
x
x
x
x
Modelagem de Requisitos
Analise O.O.
Estudo de Caso
– 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
Modelagem de Requisitos
Analise Estruturada
Estudo de Caso
– 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