engenharia de requisitos v2
TRANSCRIPT
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 1/338
X25 Treinamento e Consultoria
Treinamentos e Soluções em Tecnologia eEngenharia de Requisitos de Software
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 2/338
Fátima Saldanha [email protected]
[email protected]• 30 anos na área de TI• Especialista em APF
• CFPS -> re certificação• Consultora de TI CAIXA - Qualidade• Instrutora Métricas/Gerência de Requisitos
“ A essência da gestão é que não se pode gerenciar aquilo que nãose pode medir “ (Scott Sink & Thomas Tuttle)
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 3/338
André Barbosa [email protected]
• Gerente de Programas• Mestre em Informática
• Certificado PMP, Scrum Master e Product Owner• Professor de Pós-graduações em Engenharia de
Software e Gerência de Projetos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 4/338
Agenda• Introdução e Contextualização
– Modelos de Desenvolvimento• Definição de Requisitos• Modelagem de Negócio• Engenharia de Requisitos
– Elicitação– Análise– Especificação– Validação– Gerência de Requisitos– Métricas
• Processo Unificado
• Modelando com Diagrama de Caso de Uso• Gerência de Requisitos• Rastreabilidade
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 5/338
Introdução eContextualização
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 6/338
Objetivos
• Descrever as principais atividades daengenharia de requisitos• Introduzir técnicas para a elicitação e
análise de requisitos
• Descrever validação de requisitos• Discutir a influência do gerenciamento
de requisitos sobre as outras atividadesda engenharia de requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 7/338
Engenharia de Software
• É a aplicação de uma abordagem sistemática,disciplinada e quantificável no desenvolvimento ,operação e manutenção de software.
Sistemática – Existe um processo
Disciplinada - Processo deve ser seguido
Quantificável – Podemos medir o que estamos fazendo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 8/338
Objetivos Engenharia Software
• Qualidade
• Produtividade
• Controle de Custos e Prazos
www.swebok.org - Software Engineering Body of Knowledge
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 9/338
Conceito da Engenharia deRequisitos
Para Summerville (2003):
O processo de descobrir, analisar,
documentar e verificar as funções erestrições do sistema.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 10/338
Alvo da Engenharia de Requisitos
• Clientes Satisfeitos
• Eles Estão Satisfeitos
Quando Você:– Atende às expectativas– Entrega no prazo
– Entrega no orçamentoO Sucesso começacoma Gerência de
Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 11/338
A Grande Armadilha• 85% erros são causados por defeitos inseridos na
fase de análise de requisitos.% custo dedesenvolvimento
% defeitosintroduzidos
% defeitosencontrados
Custorelativo dacorreção
Análise deRequisitos 5 55 18 1Projeto 25 30 10 1-1.5Codificação eteste deunidade
50
Teste 10 10 50 1-5Validação edocumentação
10
Manutenção 5 22 10-100
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 12/338
Cenário Atual
• Erros mais caros são aqueles encontradosno processo de requisitos e descobertospelo usuário.
• Standish Group 350 Cia e 8.000 projetos desoftware.
• 31% cancelados e somente 16% dentro do prazo e
orçamentos em grandes 9%
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 13/338
O problema
Fatores Críticos dos Projetos%Resp
Requisitos Incompletos13,1%
Falta de envolvimento do usuário 12.4%
Falta de Recursos10.6%
Expectativas Irreais9.9%
Falta de apoio Executivo9.3%
Mudança de Requisito eEspecificação
8.7%
Falta de Planejamento8.1 %
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 14/338
Sintomas dos Problemas doDesenvolvimento de Software
Necessidades de Negócio e Usuário não atendem. Muitas mudanças de requisitos. Módulos não integram. Difícil de manter. Descoberta tardia das falhas. Baixa qualidade e iteratividade com o usuário. Baixa performance sob condições normais. Esforço não coordenado da equipe.
Problemas de build-e-release (construção elançamento de versão).
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 15/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 16/338
Questões:
• Por que leva tanto tempo para darmos umsoftware como terminado ?
• Por que os custos com desenvolvimento desoftware são tão altos ?
• Por que não conseguimos encontrar todos oserros antes de entregarmos o software para ocliente ?
• Por que ainda continuamos a ter dificuldadesem medir o progresso de como um softwareestá sendo desenvolvido ?
Analisar o Problema do Projeto
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 17/338
Analisar o Problema do ProjetoRespostas:
• 1. O software é desenvolvido/projetado, ao invés demanufaturado no sentido clássico.
• 2. Software não se desgasta com o uso: não existempeças de reposição.
• 3. Custo derivado do esforço intelectual.
• 4. Software não pode ser visto ou tocado: para analisar oprogresso de um projeto de software é preciso recorrer à suadocumentação.
• 5. Toda falha de software indica um erro no projeto ou noprocesso de desenvolvimento. Logo a manutenção desoftware é mais complexa do que a de hardware.
• 6. A maioria dos softwares é feita sob medida (porencomenda), ao invés de ser montada a partir decomponentes existentes.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 18/338
Analisar o Problema do ProjetoProblemáticas:
• Dedica-se pouco tempo à coleta de dados (requisitos dosclientes):
• Normalmente apenas um subconjunto das necessidades docliente são levadas em conta.
• Os profissionais estão sempre com muita pressa para
começar a programar ...
• A qualidade geralmente é suspeita ...
• Testes sistemáticos e tecnicamente completos raramentesão feitos;
• A flexibilidade da maioria dos softwares também é bastantelimitada;
• A concorrência com software barato mas sem qualidade,feito por pessoas sem qualificação adequada é grande.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 19/338
Analisar o Problema do Projeto
Mito:
Já temos um manual repleto de padrões eprocedimentos para a construção desoftware. Isso não oferecerá ao meu pessoaltudo que eles precisam saber ?
Realidade: Os padrões….O manual de padrões pode muito bem existir,mas será que ele é usado? Os profissionais desoftware têm conhecimento de suaexistência? Ele reflete a moderna prática de
desenvolvimento de software? É completo?Em muitos casos, a resposta a todas estasperguntas é "não".
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 20/338
Analisar o Problema do Projeto
Mito:
Se nós estamos atrasados nos prazospodemos adicionar mais programadores e tiraro atraso (chamado conceito de horda dosmongóis).
Realidade:O desenvolvimento de software não é um
processo mecânico igual à manufatura. Brooksdisse:"...acrescentar pessoas em um projeto desoftware atrasado torna-o ainda mais atrasado".
Quando novas pessoas são acrescentadas, aspessoas que estavam trabalhando devemgastar tempo educando os recém chegados, oque reduz o tempo despendido num esforço dedesenvolvimento produtivo.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 21/338
Analisar o Problema do Projeto
Mito:
Uma declaração geral dos objetivos ésuficiente para começar a escrever programas –podemos preencher os detalhes mais tarde.
Realidade:
Uma definição inicial ruim é a principalcausa de fracasso dos esforços dedesenvolvimento de software. Uma descriçãoformal e detalhada do domínio da informação,função, desempenho, interfaces, restrições de
projeto e critérios de validação é fundamental.Essas características podem ser determinadassomente depois de cuidados comunicação entreo cliente e o desenvolvedor.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 22/338
Analisar o Problema do ProjetoMito:
Os requisitos de projeto modificam-se
continuamente, mas as mudanças podem serfacilmente acomodadas, porque o software éflexível.
Realidade:
É verdade que os requisitos de software semodificam, mas o impacto da mudança variade acordo com o tempo em que ela éintroduzida. Se uma séria atenção for dada àdefinição inicial, os primeiros pedidos demudança podem ser acomodados facilmente.
• Definição . . . . . . . . . . . . . . . . . x• Desenvolvimento . . . . . . . . . . 1.5x a 1.6x• Manutenção . . . . . . . . . . . . . . 60x a 100x
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 23/338
Analisar o Problema do Projeto
Mito:
Assim que escrevermos o programa e ocolocarmos em funcionamento nosso trabalhoestará completo.
Realidade:
Alguém disse certa vez que "quanto maiscedo se começa a 'escrever o código', maistempo demora para que se consiga terminá-lo".Os dados da indústria indicam que entre 50 e70% de todo esforço gasto num programa serão
despendidos depois que ele for entregue pelaprimeira vez ao cliente.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 24/338
Analisar o Problema do Projeto
Mito:
A única coisa a ser entregue em umprojeto bem sucedido é o programafuncionando.
Realidade:
Um programa funcionando é somenteuma parte de uma configuração de softwareque inclui: plano, especificação de requisitos,projeto, estrutura de dados, listagem,especificação de teste, programa funcionando.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 25/338
Analisar o Problema do Projeto
Mito:
Enquanto não tiver o programa"funcionando", eu não terei realmente nenhumamaneira de avaliar sua qualidade.
Realidade: ex RTPUm dos mecanismos mais efetivos de
garantia da qualidade de software pode seraplicado desde o começo de um projeto - arevisão técnica formal. As revisões de softwaresão um "filtro da qualidade" que têm sido
consideradas mais eficientes do que arealização de testes para a descoberta decertas classes de defeitos de software.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 26/338
Principais Fatores deFalha dos Projetos
Requisitos e Especificações IncompletosRequisitos e Especificações Incompletos
Objetivos Não Estavam ClarosObjetivos Não Estavam Claros
Requisitos e Especificações InstáveisRequisitos e Especificações Instáveis(Mudanças)(Mudanças)
Falta de “Input” do UsuárioFalta de “Input” do Usuário
Falta de Suporte do NívelFalta de Suporte do NívelExecutivoExecutivo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 27/338
Um caso comum !!
O sistema que queremos deve fazer isto,isto, ..., e nesse caso também isto...;
- Sim, Sim, estou anotando...
- Conversei com os usuários ebasicamente este é o sistema queteremos que desenvolver;
- Sim chefe;
- Ótimo, começaremos a especificar osrequisitos imediatamente.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 28/338
Motivação
Quatro meses depois ...- Senhores usuários, após o emprego dasmais modernas técnicas de especificação,produzimos este documento que descreve
minuciosamente o Sistema;- Ótimo! Bom! Hum! ... É um documentocom 300 páginas e todos estes gráficos,tabelas. Enfim, vamos analisá-los evoltamos a falar;
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 29/338
Motivação
Mais um mês e meio ...- Sr. Analista, nosso pessoal analisou com
cuidado o documento. Tivemos muitasdificuldades em entendê-lo. Mas o que
percebemos é que NÃO FOMOSCORRETAMENTE ENTENDIDOS!!!- Como não? Tudo que está aí foi fruto de
nosso entendimento pessoal.
REALMENTE VOCÊS NÃO SABEM O QUEQUEREM!!!
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 30/338
Motivação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 31/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 32/338
• Comprometimento da Alta Administração
• Treinamento e Educação
• O uso adequado das técnicas, métodos, eferramentas.
• Utilização dos Modelos e padrões de
Qualidade deSoftware
• Documentação do Sistema
A Crise de Software:existe solução?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 33/338
Modelos
Vi ã G l
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 34/338
Visão Geral
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 35/338
Modelos de Desenvolvimento
Descrições abstratas do processo de
desenvolvimento de software, mostrando asatividades e dados usados no ciclo de vida dosoftware.Os principais modelos existentes são:
- Modelo clássico (ou em cascata ouSequencial);- Prototipagem (ou Prototipação);- Incremental (iterativo)
- Modelo espiral (ou baseado em riscos);- Transformação formal (ou refinamento);
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 36/338
Modelos de Desenvolvimento
Modelo Clássico em Cascata
Requisitos
Análise
Design
Construção
Teste
Manutenção
Vantagens?•Oferece uma maneira de tornaro processo mais visível.•Facilita o planejamento.•Fixa pontos específicos para aescrita de relatórios.•Indicado para quando os
requisitos do sistema são muitobem entendidos.esvantagens?
Projetos reais raramente seguem o fluxoeqüencial proposto por este modelo: na maioriaos casos existe interação e superposição.Raramente os clientes (usuários) declaram todass exigências de uma vez, no início do projeto.Boa parte dos programas não estará disponível atém ponto adiantado no cronograma do projeto: éeralmente difícil convencer o usuário de que éreciso paciência
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 37/338
Modelos de Desenvolvimento
Modelo Incremental/Interativo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 38/338
Modelos de Desenvolvimento
Modelo Incremental/Iterativo
Vantagens?•Indicado para os projetos onde já se tem uma compreensão dassuas características essenciais e tem-se um deadline rígido paraimplantá-lo.
•Desenvolvimento da primeira versão do sistema o mais rápidopossível;
•Modificações sucessivas até que o sistema seja consideradoadequado;
•A primeira versão pode ser implementada por poucas pessoas ecom a aceitação do produto pode-se adicionar mais pessoas paraacelerar odesenvolvimento.
•O primeiro incremento (versão) é o núcleo do software. Nesta
d l d l i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 39/338
Modelos de Desenvolvimento
Modelo Incremental/Iterativo
Vantagens?•As características suplementares (algumas já conhecidas eoutras não) são entregadas apenas nas versões posteriores.
Desvantagens?•Visibilidade Fraca•Estrutura Desorganizada•Habilidades Especiais são requeridas
M d l d D l i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 40/338
Modelos de Desenvolvimento
Prototipação
Especificação
Desenvolvimento
Validation
Versão Inicial
Vesão InicialVesão InicialVersõesIntermediárias
Versão Final
Descrição Alto Nível
M d l d D l i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 41/338
Modelos de Desenvolvimento
Prototipação
Vantagens?•Protótipos contribuem para melhorar a qualidade daespecificação dos futuros programas, o que leva à diminuição dosgastos com manutenção.
•Em alguns casos, o treinamento dos usuários pode até ser feitoantes do produto ficar pronto.
•Algumas partes do protótipo podem vir a ser usadasnodesenvolvimento do sistema final.
Obs.: comum em métodos ágeis!
M d l d D l i t
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 42/338
Modelos de Desenvolvimento
Prototipação
Desvantagens?•Em geral o grande argumento contra a construção de protótiposé o custo.
•A construção do protótipo atrasa o início daimplementação do sistema final.
• Atrasos são um dos maiores problemas dos projetos desoftware.• Construir um protótipo pode não ser tão mais rápido doque construir o sistema final.
• Se os ambientes utilizados forem diferentes este custoserá um custo extra.
F G é i d Q i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 43/338
Fases Genéricas de QuaisquerModelos
Independente do modelo, as fases a seguir sempre
precisam existir, mesmo que não seja trivial identificá-lasno projeto.
Definição - O QUÊ.•Análise dos Requisitos•Planejamento
•Análise do Sistema
Desenvolvimento - COMO.•Projeto•Codificação• Testes
Manutenção - MUDANÇAS•Correção•Adaptação•Melhoramento
Foco da Gestãode Requisitos
F G é i d Q i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 44/338
Fases Genéricas de QuaisquerModelos
Independente do modelo, as fases a seguir sempre
precisam existir, mesmo que não seja trivial identificá-lasno projeto.
Definição - O QUÊ.•Análise dos Requisitos•Planejamento
•Análise do Sistema
Desenvolvimento - COMO.•Projeto•Codificação• Testes
Manutenção - MUDANÇAS•Correção•Adaptação•Melhoramento
Foco da Gestãode Requisitos
M d l d M t id d CMMI
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 45/338
CENÁRIO ATUAL
•Globalização da Economia•Mudanças Tecnológicas Velozes
•Crescimento da Complexidade Sistemas
•Escassez de Recursos Humanos
•Clientes mais Exigentes
QUALIDADE E PRODUTIVIDADE
Modelo de Maturidade CMMI
GERÊNCIA DE REQUISITOS E CMMI SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 46/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
• CMMI (CMM Integration): framework/suíte queintegrou os seguintes modelos:– CMM for Software– Systems Engineering CM (SECM)– The Integrated Product Development CMM (IPD-CMM)
• As organizações podem usar o CMMI para ajudar:
– definir objetivos e prioridades da melhoria do processo;
– melhorar processos;
– prover um guia para assegurar processos estáveis,capacitados e maturos;
– servir com um guia para a melhoria dos processoorganizacionais.
Modelo de Maturidade CMMI
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 47/338
•Qualidade do Processo de Software
•Qualidade do Produto
•Processo Controlado
Indicadores
Modelo de Maturidade CMMI
Modelo de Maturidade CMMI
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 48/338
Melhor Gerênciada Terceirização
Aumento da Produtividade
Melhora da Qualidade
Redução doCustoda ManutençãoReduçãodo
Retrabalho
Gerência de Riscos
Garantia daSatisfação
do Cliente
Modelo de Maturidade CMMI
Modelo de Maturidade CMMI
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 49/338
Métricas, Modelos,Medições e Análises
Foco noCliente
Melhoriado Processo
Lado Humano
da Qualidade
Total Quality Management
Melhoria Contínua
Modelo de Maturidade CMMI
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 50/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
•Modelos de referência de práticas de engenharia desoftware, como o CMM (Capability Maturity Model) e,mais recentemente, o CMMI, consideram ogerenciamento de requisitos como sendo uma dasprimeiras etapas para alcançar a maturidade
organizacional.• Para haver o gerenciamento é preciso que o
processo de gerenciamento de requisitos estejaimplantado na empresa.
• A seguir, será visto o gerenciamento de requisitos naperspectiva do CMMI-SE/SW.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 51/338
Qualidade Total
OTIMIZAÇÃO5
DEFINIDO3
REPETÍVEL2
INICIAL1
NÍVEIS DENÍVEIS DEMATURIDADEMATURIDADE
GERENCIADO4
ControleGerencial
Básico
Definiçãodo Processo
Mediçãodo Processo
Controledo Processo
MODEL
O CMMI
MODELO CMM
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 52/338
MODELO CMM
1 - INICIAL O desenvolvedor é ogrande artista.
2 - REPETITIVO •Gerência deConfiguração de Software•Garantia de Qualidadede Software
•Gerência de Contrato desoftware•Superv.Acomp.deProj.Software•Planejamento do Projetode Software
•Gerência de RequisitosMétrica
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 53/338
3 - Definido •Revisão por parceiros•Coordenação Grupos•Engenharia Produtosoftware•Gerência de SoftwareIntegrada•Treinamento•Definição ProcessoOrganização
•Foco no Processo daOrganização
4 - Gerenciado Gerência de QualidadeGerência Quantitativa-Processosde Medidas
Gerência da Evolução doProcessoEvolução de TecnologiaPrevenção de defeitos
5 -
Otimizado
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 54/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
CMMI – Breve Histórico– Capability Maturity Model (CMM) para Software
• Ainda não era o CMMI...– Desenvolvido inicialmente pelo SEI (Software Engineering
Institute) da Carnegie-Mellon, no início dos anos 90– Um modelo de referência de práticas maduras em uma
disciplina específica, usado para avaliar uma capacidade deum grupo para executar aquela disciplina
– Feito para ser genérico– Disponível publicamente, documentado, repetível e ‘vivo’– Usado como balizador para melhoria de processos de
software, recursos humanos e engenharia de sistemas.– Segundo o modelo CMMI, quanto maior o controle sobre o
processo de desenvolvimento, mais madura é a organização.
GERÊNCIA DE REQUISITOS E CMMI SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 55/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
Software
CMM
V1.1
SECAM
EIA/IS 731
SECM
SE-CMM
Time 1993 2002
Software
CMM
V2.0c
Timeline not to scaleIPD-CMM
v0.98
SA-CMM
v1.01
CMMI
V1.1xCMMI
V1.0x
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 56/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
Por estágios:
cinco níveis dematuridade
cada nível dematuridade definido por (Key) Process Areas
(KPAs/PAs) provê um guia para aimplementação
Contínua:
cinco ou seis níveis decapacidade
cada nível de capacidadedefinido por PAs e Práticas Gerais
provê flexibilidade máxima por focar em áreas de processo
específicas de acordo com asmetas e os objetivos do negócio
O CMMI possui duas representações:
por estágios (staged )
contínua
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 57/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
A organização recebe uma classificação dematuridadeA maturidade do processo é classificada emníveis (1 a 5) – cada nível é definido poragrupamento de áreas de processo (PAs) Todas as áreas de processo dentro de cadanível devem ser satisfeitas para atingir umaclassificação específica .
Ê
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 58/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
http://www.borland.com/resources/cmmi/staged/static/CMMI%20Staged%20MainPage.html
Ê
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 59/338
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
5Optimizing
Process change management
Technology change managementDefect prevention
4Managed
3Defined
2Repeatable
1
Initial
Software quality management
Quantitative process management
Peer Reviews
Intergroup coordination
Software product engineering
Integrated software managementTraining program
Organization process definition
Organization process focus
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planningRequirements management
Process improvement
is institutionalized
Product and process
are quantitatively
controlled
Technical practices are
integrated with
management practicesand institutionalized
Project management
practices are
institutionalized
Process is informal and
ad -hoc
Key Process AreaLevel Focus Results
Risk
Key Process Area
Quality
From Software Engineering Institute (SEI)
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 60/338
GERÊNCIA DE REQUISITOS E CMMI SE/SW
Área de Processo “Gerenciamento de Requisitos”
segundo o CMMI:
• Propósito– Gerenciar os requisitos dos produtos do projeto e de seus
componentes e identificar inconsistências entre estesrequisitos e aqueles que foram identificados nos planos deprojeto e nos artefatos.[1]
• Verificado:
– No Nível 2 quando se usa a Representação por Estágios– Na Categoria Engenharia na Representação Contínua
[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 82 (stagedrepresentation)
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 61/338
[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 83 (stagedrepresentation)
• Meta
– Os requisitos são gerenciados e as inconsistências entreos planos de projeto e os artefatos são identificadas [1]
Manter a coleção de requisitos aprovados (baseline) e‘rastrear’ as mudanças nesses requisitos.
Manter os relacionamentos entre requisitos, os planosde projeto e outros artefatos.
Identificar inconsistências entre os requisitos, o plano deprojeto e outros artefatos.
Tomar medidas corretivas, quando necessário.
Isso significa:
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 62/338
GERÊNCIA DE REQUISITOS E CMMI SE/SW
• Práticas e Artefatos– Obter um entendimento dos requisitos:
• Lista de critérios para distinguir os ‘provedores’ de requisitos apropriados;• Critérios para avaliação e aceitação de requisitos;• Resultados da análise por meio dos critérios.
– Obter um comprometimento em relação aos requisitos:• Verificação de impactos nos requisitos• Aceites documentados em relação aos requisitos e às mudanças nos
requisitos– Gerenciar mudanças nos requisitos
• Status dos requisitos• Repositórios de requisitos
– Manter rastreabilidade bidirecional• Matriz de Rastreabilidade de Requisitos• Sistema de Acompanhamento de Requisitos
– Identificar inconsistências entre requisitos e demais artefatos• Documentação de Inconsistências, incluindo fontes, condições e rationale• Ações corretivas
[1] Capability Maturity Model®Integration (CMMISM) Version 1.1, pp. 82 (staged
GERÊNCIA DE REQUISITOS E CMMI-SE/SW
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 63/338
GERÊNCIA DE REQUISITOS E CMMI SE/SW
Relações entre o Gerenciamento de Requisitos e as outras Áreas deProcesso
GERÊNCIA DE REQUISITOS X GERÊNCIA POR
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 64/338
GERÊNCIA DE REQUISITOS X GERÊNCIA PORREQUISITOS
•Importância da Gerência de Requisitos
Segundo o CMMI, a Gerência por Requisitos (ou Gerência de Requisitos)trata de um aspecto fundamental e crítico em qualquer processo desoftware: estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo software.
• Aspectos fundamentais na Gerência de Requisitos:– Estabilidade– Rastreabilidade
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 65/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 66/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 67/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 68/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 69/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 70/338
Requisito - Definição
O que é um requisito?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 71/338
O que é um requisito?• Uma condição ou capacidade necessitada por um
usuário para resolver um problema ou atingir umobjetivo.
• Uma condição ou capacidade que deve ser
atendida ou contemplada por um sistema oucomponente de sistema para satisfazer umcontrato, padrão, especificação ou outrodocumento formalmente imposto.
• Uma representação documentada de umacondição ou capacidade conforme ilustradas nositens anteriores.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 72/338
Regras de Negócio
• Políticas Corporativas• Regulamentos governamentais• Práticas contábeis• Padrões do negócio• Algoritmos , Cálculos do negócio
É possível rastrear a origem de certas
funcionalidades que são derivadasatravés de certas regras de negócio
Regras de Negócio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 73/338
Regras de Negócio
• As Regras de Negócio são todos oscálculos, consistências, validações, processamentos e eventos de um sistema.
• Estas Regras são especificadas em
linguagem natural, normalmente sem padronização.• Depois de especificadas, estas Regras são
enviadas para a programadores, que vãotransformar a especificação em código
fonte em alguma linguagem de programação.
Fronteira
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 74/338
Fronteira
•É uma interface conceitual entre a aplicação e o mundo externo.
•Define o que é externo à aplicação.•É definida pela visão de negócio do usuário e não por considerações
tecnológicas.• Age como uma membrana por onde passam dados processados pelas
transações, entrando ou saindo do sistema.
•Quando o escopo da contagem envolver mais de uma aplicação, asfronteiras entre as aplicações devem ser determinadas.
Escopo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 75/338
Escopo
Define as funcionalidades que serão
incluídas em um Sistema.
Novo sistema inclui todas as funcionalidades .
O escopo define um conjunto (ou subconjunto)
das funcionalidades do software.
Pode incluir mais de uma aplicação
Engenharia de
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 76/338
gRequisitos
Elicitação
Requisitosdesenvolvimento
Requisitosdesenvolvimento
GerenciamentoRequisitos
Análise Especificação Validação
clarear
Reavaliar
Reescrever
Corrigir e encerrar aslacunas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 77/338
Processo
Entidade
Fronteira
A menor Unidade Lógica
M d l F i iM d l F i i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 78/338
Modelos FuncionaisModelos Funcionais
O que é uma funcionalidade ?• Uma Função• Uma necessidade do negócio, do usuário.
• Uma Capacidade necessitada por um usuário
para resolverum problema ou atingir um objetivo
Algo Visto, Tangível, com sentido tanto parausuários quanto para desenvolvedores que
trabalhando em conjunto produzem umdeterminado resultado
Nota : Funcionais,Qualidade (ISO 9126) e
Técnicos.
O que é um requisito?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 79/338
O que é um requisito?
• Tanto pode ser uma declaraçãoabstrata de alto nível de um serviçoou restrição do sistema quantouma especificação funcionalmatemática detalhada
O que é um requisito?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 80/338
O que é um requisito?(Sommerville and Sawyer 1997)
1. Requisitos são....a especificação do que pode serimplementado.
2. Eles são a descrição de como o sistema poderá se comportar,ou uma propriedade ou atributo do sistema.
3. Eles podem ser também uma restrição no processo dedesenvolvimento do sistema
4. Atributos descrevem não o que o sistema faz mas como tãobem ele faz
Exemplos de softwares que satisfazem os requisitosfuncionais mas não satisfazem a expectativa do usuário emqualidade.
5. Outros tipos de requisitos podem impor restrições que os
desenvolvedores devem tratar que limitam em função datecnolo ia um bom desem enho do software.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 81/338
Tipos de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 82/338
Tipos de Requisitos
Os nomes mais utilizados são:• Requisitos do Sistema• Requisitos funcionais• Requisitos de Software
• Requisitos do Produto• Requisitos Técnicos• Restrições• Artefatos
• Requisitos• Requisitos do Negócio• Requisitos do Usuário
Níveis de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 83/338
Níveis de Requisitos
1. Requisitos do Negócio
1. Requisitos do Usuário
1. Requisitos Funcionais
1. Requisitos do Sistema
1. Requisitos Não Funcionais
Hierarquia de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 84/338
Hierarquia de Requisitos
Requisitos
Não-funcionais
Organização
Funcionais Domínio
Produto Externo
SistemaUsuário =df
Tipos de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 85/338
pos de equ s os
• Requisitos do Usuário– Declarações em linguagem natural com
diagramas de serviços que o sistema deveoferecer e suas restrições operacionais.Escrito para os clientes
• Requisitos do Sistema– Documento estruturado com descriçõesdetalhadas sobre os serviços do sistema.Contrato entre cliente e fornecedor
• Especificação do Software– Descrição detalhada do software que servecomo base para projeto ou implementação.Escrito para desenvolvedores
Requisitos Funcionais e Não-
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 86/338
qFuncionais
• Requisitos Funcionais– Declarações sobre o que o sistema deveoferecer, como o sistema deve reagir adeterminadas entradas e como o sistema devecomportar-se em situações especiais
• Requisitos Não-Funcionais– Restrições sobre funções ou serviços oferecidas
pelo sistema (tempo, processo dedesenvolvimento, padrões, etc)
• Requisitos de Domínio– Requisitos vindos do domínio da aplicação do
sistema e que refletem características dessedomínio (funcionais/não-funcionais)
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 87/338
Requisitos Funcionais
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 88/338
q(Exemplos)
• O usuário poderá pesquisar todo oconjunto inicial de banco de dados ouselecionar um sub-conjunto dele
• O sistema deve oferecer visualizadores
apropriados para o usuário lerdocumentos armazenados
• A todo pedido deve ser associado umidentificador único (PID), o qual o usuário
pode copiar para a área dearmazenamento permanente da conta
Requisitos Não-Funcionais
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 89/338
q
• Definem propriedades e restrições dosistema (tempo, espaço, etc)• Requisitos de processo também podem
especificar o uso de determinadas
linguagens de programação, método dedesenvolvimento
• Requisitos não-funcionais podem sermais críticos que requisitos funcionais.Não satisfaz, sistema inútil.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 90/338
Medidas de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 91/338
q(Não-Funcionais)
ropriedade Medidaelocidade Transações processadas/seg
Tempo de resposta do usuário/eventomanho K bytes
No de chips de RAMcilidade de uso Tempo de treinamento
No de quadros de ajudaonfiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade Taxa de ocorrência de falhas
obustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha
rtabilidade Percentual de declarações dependentes do destiNo de sistemas destino
Requisitos Não-Funcionais
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 92/338
q(Exemplos)
• Requisitos do Produto– Toda consulta ao banco de dados baseada
em código de barras não deve exceder 5 s
• Requisitos Organizacionais– Todos os documentos entregues devem
seguir o padrão de relatórios XYZ-00
• Requisitos Externos– O sistema não deve usar informações
pessoais do usuário com os operadores dosistema
Requisitos de Domínio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 93/338
q
• Derivados do domínio da aplicaçãoe descrevem características dosistema e qualidades que refletemo domínio
• Podem ser requisitos funcionaisnovos, restrições sobre requisitosexistentes ou computações
específicas• Se requisitos de domínio não forem
satisfeitos, o sistema pode tornar-
se não prático
Requisitos de Domínio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 94/338
q(Problemas)
• Entendimento– Requisitos são descritos na linguagem
do domínio da aplicação
– Não é entendido pelos engenheiros desoftware que vão desenvolver aaplicação
• Implicitude
– Especialistas no domínio entendem aárea tão bem que não tornam todos osrequisitos de domínio explícitos
Requisitos de Domínio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 95/338
q(Exemplo 1)
• A desaceleração do trem deve sercomputada através da fórmula
Dtrem
=Dcontrole
+Dgradienteonde ...
Outra Classificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 96/338
• Requisitos Mutáveis– Mudanças do ambiente da organização
Ex:financiamento do tratamento dospacientes,diferentes informações sejam
coletadas
• Requisitos Emergentes– Aparecem pela maior compreensão durante
o desenvolvimento do sistema.
Outra Classificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 97/338
• Requisitos conseqüentes– Requisitos que resultam da modificação dosprocessos da organização e criação de novosmeios de trabalho, que geram novosrequisitos.
• Requisitos de compatibilidade.– Requisitos que dependem de outros sistemas
ou processos do negócio. A medida que elesse modificam ,os requisitos de
compatibilidade podem ter que evoluir.
Outra Classificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 98/338
• Requisitos Permanentes
- Relativamente estáveis derivados daatividade principal da empresa ex: Um
hospital terá sempre requisitos relativosaos pacientes, aos médicos, àsenfermeiras e aos tratamentos w Podemser derivados dos modelos de domínio.
Outra Classificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 99/338
• Requisitos Voláteis
- Provavelmente vão se modificardurante o desenvolvimento do sistema
ou depois que o sistema já estiver emoperação. ex:políticas governamentaissobre assistência médica.
Priorização
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 100/338
• Requisitos podem ser vistos em trêsclasses distintas– Essenciais– Importantes
– Desejáveis
• Em princípio, sistema deve resolvertodos os requisitos de essenciais paradesejáveis
Regras de Negócio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 101/338
Regras de Negócio
• Políticas Corporativas• Regulamentos governamentais• Práticas contábeis• Padrões do negócio
• Algoritmos , Cálculos do negócio
É possível rastrear a origem de
certas funcionalidades que sãoderivadas através de certas regras denegócio
Regras de Negócio
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 102/338
g g
• As Regras de Negócio são todos oscálculos, consistências, validações,processamentos e eventos de um sistema.
• Estas Regras são especificadas emlinguagem natural, normalmente sempadronização.
• Depois de especificadas, estas Regras sãoenviadas para a programadores, que vãotransformar a especificação em códigofonte em alguma linguagem deprogramação.
Qualidades de um requisito de
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 103/338
software
• Verificabilidade• Ranqueamento por importância ou
estabilidade• Modificabilidade
• Rastreabilidade• Inteligibilidade• Corretude• Completude• Consistência• Não-ambiguidade
Qualidades de um requisito:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 104/338
verificabilidade
• Um requisito é verificável quando:– Existe um processo finito e de custo efetivo no qualuma pessoa ou máquina pode checar se o produtoatende aos requisitos
O sistema suporta 1000 usuários simultâneos
O sistema consegue responder a uma consulta arbritária em500mseg. A cor apresenta um tom agradável de verde O sistema é capaz de ficar disponível 24 horas por dia 7 dias na
semana O sistema consegue exportar dados em formato separado por
vírgula Esses requisitos são verificáveis?
Caso contrário, qual seria a melhor forma de definí-los?
Qualidades de um requisito:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 105/338
rastreabilidade
Solicitações dos envolvidos
Características
Casos de uso Especificações
suplementares
Qualidades de um requisito:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 106/338
não-ambiguidade• Um requisito é não-ambíguo quando:
– Só tem uma interpretação possível
Requisito A
“A deve fazerB para C”
“A deve fazerB para C”
“A deve fazer
B para C”
Explorando a ambiguidade: uma
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 107/338
observação
Fonte: Rational University
O que um requisito nãol
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 108/338
contempla
• Design – como atingir os requisitos– O modelo de design especifica componentes de umsistema e/ou interfaces com outros subcomponentes
• Verificação – como saber se os requisitos foram
alcançados– O modelo de teste especifica casos e procedimentos deteste
• Dados do projeto – quando os requisitos serãoalcançados– O plano de desenvolvimento de software especifica
calendários, planos de verificação e validação, e planosde gerenciamento de configuração
Desafios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 109/338
• Compreensão do domínio doProblema
•Achar o verdadeiro usuário• Evolução contínua dos Requisitos(Scope Screep)
• Definição de domínio Sistemas ou áreasfuncionais dentro dos sistemas que exibemfuncionalidades similares
Verdades e Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 110/338
1. Se você não captura direito os requisitos, nãoimporta como você fará bem o resto doprojeto.
2. Desenvolvimento de requisitos é um processode invenção e descoberta, não simplesmenteum processo.
3. Mudanças acontecem.4. O interesse de todos os envolvidos influencia
no processo.
5. Envolvimento do cliente é a maiorcontribuição crítica para a qualidade dosoftware
6. O cliente não está sempre certo , maissempre tem algo importante.
Antes dos Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 111/338
Antes dos Requisitos
Modelagem de Negócios
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 112/338
Com a crescente complexidade dossistemas corporativos enecessidade de integração entreeles, veio a necessidade de ser criar
modelos de mais alto nível deabstração e estes modelos foram seintegrando às disciplinas dedesenvolvimento de software.
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 113/338
Requisitos do Negócio
• Nível superior , declarações dasmetas, objetivos e necessidades daempresa.
• São desenvolvidos e definidosatravés de análise da empresa• Descrevem as razões pelas quais
um projeto foi iniciado, o objetivosque o projeto vai alcançar, e asmétricas que serão usadas paramedir seu sucesso
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 114/338
Requisitos do Negócio
• Descrevem as necessidades daorganização como um todo, e nãogrupos ou partes interessadas nele.
Modelagem de Negóciosi i d á i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 115/338
Requisitos do Usuário(Stakeholder)
• Necessidades que um ator tem ecomo as partes interessadas irãointeragir com a solução .
• servem como uma ponte entre asnecessidades empresariais e asdiversas classes de requisitos da
solução• São desenvolvidos e definidosatravés da análise de requisitos
Modelagem de NegóciosR i i d S l ã
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 116/338
Requisitos da Solução
• descrevem as características deuma solução que atendam aosrequisitos de negócio e aosrequisitos dos Usuário interessadas.
• Eles são desenvolvidos e definidosatravés de análise de requisitos
Modelagem de NegóciosR i it d S l ã
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 117/338
Requisitos da Solução
• Divididos em sub-categorias paradescrever a solução de software
– Requisitos Funcionais ▷ ▷
descrevem o comportamento e asinformações que a solução vai gerir. Acapacidade que o sistema será capazde realizar em termos de
comportamentos ou Operações .
Modelagem de NegóciosR i it d S l ã
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 118/338
Requisitos da Solução– Requisitos Não Funcionais▷ ▷– condições que descrevem as
condições ambientais em que asolução deve permanecer .
– Qualidades que os sistemas devemter.– São conhecidos como os requisitos de
qualidade : Capacidade, Velocidade,
Segurança, Disponibilidade ,Arquitetura da informação eUsabilidade
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 119/338
Negócio
Necessidades
Objetivo: mapear e documentar os processos da cadeia devalor da organização para melhor atingir sua missão,estratégia, metas e objetivos.
Permite identificar mais facilmente quais atividadesautomatizar através de software para obter melhordesempenho.
Software
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 120/338
Como modelar?RUP oferece casos de uso de negócio.O mercado tem adotado o BPMN.
O BPMN fornece uma notação necessária para
expressar os processos de negócio em um único diagramade processo de negócio (Business Process Diagram – BPD)
– Fornece uma notação que compreensível por todos osutilizadores, analistas e técnicos do negócio.
– Garante que linguagens projetadas para a automação eexecução de processos de negócio, tais como o BPEL4WS e o
BPML, sejam visualmente expressos com uma notaçãocomum.
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 121/338
Abordagem BPMN
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 122/338
Artefatos
Objeto Descrição Figura
Objetos de dados O objeto de dado é um mecanismopara mostrar como os dados sãorequeridos ou produzidos poratividades. São conectados àsatividades com as associações.
Grupo Um grupo é representado por umretângulo e pode ser usado parafinalidades de documentação ou deanálise.
Anotações As anotações são mecanismos
para fornecer informaçõesadicionais para o leitor de umdiagrama BPMN.
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 123/338
Objeto Descrição FiguraEvento É algo que acontece durante um processo
do negócio. Estes eventos afetam o fluxodo processo e têm geralmente uma causa(trigger) ou um impacto (result). Há trêstipos de eventos, baseados sobre quandoafetam o fluxo: Start, Intermediate, e End.
Atividade É um termo genérico para um trabalhoexecutado. Os tipos de atividades são:
Tarefas e sub-processos. O sub-processo édistinguido por uma pequena cruz nocentro inferior da figura.
Gateway É usado para controlar a divergência e aconvergência da seqüência de um fluxo.Assim, determinará decisões tradicionais,como juntar ou dividir trajetos.
Objetos de Fluxo
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 124/338
Objeto Descrição Figura
Fluxo deseqüência
É usado para mostrar a ordem(seqüência) com que as atividadesserão executadas em um processo.
Fluxo de
mensagem
É usado mostrar o fluxo das
mensagens entre dois participantesdiferentes que os emitem e recebem.
Associação É usada para associar dados, texto, eoutros artefatos com os objetos defluxo. As associações são usadas para
mostrar as entradas e as saídas dasatividades.
Objetos de Conexão
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 125/338
Objeto Descrição FiguraPool Um pool representa um
participante em um processo.Ele atua como um containergráfico para dividir umconjunto de atividades de
outros pools, geralmente nocontexto de situações de B2B.
Lane Uma lane é uma subdivisãodentro de um pool usado paraorganizar e categorizar as
atividades.
Swimlanes e Pools
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 126/338
Exemplo BPMN: marcação de consulta médica.
Modelagem de Negócios
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 127/338
Exemplo BPMN: subprocesso de consulta médica.
Modelagem de NegóciosExemplo: RUP: casos de uso de negócio abordagem estrutural
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 128/338
Exemplo: RUP: casos de uso de negócio, abordagem estrutural.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 129/338
Engenharia de Requisitos
Engenharia de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 130/338
Definição Genérica:
- Estabelecer o que o cliente requer de um sistemade software
Definição da IEEE Institute of Electrical and
Electronics Engineers :-Processo de aquisição, refinamento e verificaçãodas necessidades do cliente, com o objetivo deobter uma especificação correta e completa dosrequisitos.
Engenharia de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 131/338
Definição de Boehm:
Disciplina para desenvolver uma especificação completa,consistente e não ambígua do software;Um acordo entre as partes descrevendo o que o produto desoftware irá fazer.
Definição de B. Meyer:Especificar o documento de requisitos de um software édefinir de uma forma completa e não ambígua:- as características externas do softwareoferecidas aos usuários;- a forma pela qual o software é integrado ao
sistema.
Engenharia de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 132/338
Definição de A. Davis:
- Durante a fase de requisitos, é necessárioanalisar, e portanto entender o problema a serresolvido.- A análise do problema é a atividade que inclui o
entendimento das necessidades do usuário bemcomo as limitações impostas na solução.
O Processo da Engenharia deRequisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 133/338
Requisitos
Modelagem deNegócio
Elicitação derequisitos
Modelagem de
Requisitos
Análisede requisitos
Especificaçãode requisitos
Documento de
requisitos
Validaçãode requisitos
Engenharia de Requisitos
Gerenciamento deRequisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 134/338
Requisitos• Gerenciar as mudanças das evoluções
dos requisitos que já foram instalados egeraram um release.
• Gerenciar requisitos também incluirastrear o status de um requisitoindividual.
• Gerenciar requisitos possibilita rastrearos requisitos da sua origem atéelementos de design, módulos de código
e testes
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 135/338
Elicitação de Requisitos
(O quê?)
Análise de ProblemasIdentifique stakeholders para o
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 136/338
Elicitar
Requisitos
Expandir a lista desoluções do
stakeholder
Escolher as melhoressoluções para alcançar os
objetivos.Melhor solução
identificada
Problema validado/ajustado
Problema de NegócioDefinido
Problema Atualidentificado e definido
Identifique stakeholders para o problema.
Análise da Causa-Raiz.
Reavaliar qual é a melhor idéia de solução.
Entendimento dosProblemas no
Contexto dosObjetivos de Negócio.
Problemade
Negócio
Idéia deSolução ou
Oportunidade
Elicitação de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 137/338
• ELICITAR: descobrir, tornar explícito,obter o máximo de informações para oconhecimento do objeto em questão;
• Identificar os fatos que compõem osrequisitos do sistema a fim de prover omais correto e mais completoentendimento do que é demandado
daquele software.
• Entender o processo como um todo.
Elicitação de Requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 138/338
• Envolvimento com o ambiente detrabalho do cliente, ou seja, se misturarcom os funcionários,observar, aprender,e questionar, de forma a superar a
ignorância do domínio do problema;• É preciso entender a razão porque as
coisas são feitas da forma que são.
Elicitação de requisitos:dificuldades
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 139/338
dificuldades
• Usuários podem não ter uma idéia precisado sistema por eles requerido;• Usuários têm dificuldades para
descreverem seu conhecimento sobre odomínio do problema;
• Usuários e analistas têm diferentes pontosde vista do problema (por teremformações diferentes)
• Usuários podem antipatizar com o novo
sistema e se negar a participar daelicitação (ou mesmo fornecerinformações errôneas).
Elicitação de requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 140/338
• É uma atividade de negociação ecomunicação entre especialistas e nãoespecialistas;
• A qualidade da comunicação entre as
partesenvolvidas depende:– de um bom entendimento;– de uma análise rigorosa.
• Resultado: Uma declaração em linguagemnatural dos serviços que o sistema deveráprover e suas limitações operacionais.
Atividades da Elicitação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 141/338
Entendimento do domínio da aplicação• O conhecimento do domínio da aplicação é o
conhecimento geral onde o sistema seráaplicado
Entendimento do problema
• Os detalhes específicos do problema do clienteonde o sistema será aplicado deve serentendido
Entendimento do negócio• Você deve entender como os sistemas
interagem e contribuem de forma geral com osobjetivos do negócio
Entendimento das necessidades e limitações dosstakeholders sistema
Produtos da Elicitação• Lista dos usuários do sistema
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 142/338
• Lista dos usuários do sistema
• Entendimento do fluxo de trabalho dosusuários
• O papel de cada departamento/setorque iráutilizar o sistema
• O que atrapalha o andamento doprocesso dousuário e o que pode ser feito paramelhorar.
Técnicas de Elicitação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 143/338
• Técnicas especiais que podem ser usadaspara coletar conhecimento sobre osrequisitos dos usuários
• Este conhecimento deve ser estruturado
• Problemas da elicitação– Tempo– Engenheiros de software
– stakeholders
Técnicas de Elicitação• Entrevistas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 144/338
• Entrevistas• Leitura de documentos• Questionários• Análise de protocolos ETNOGRAFIA• Participação ativa dos usuários
• Cenários• Observações e análise sociais• Prototipação
Técnicas continuação)
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 145/338
• Levantamento orientado a pontos devista
• Workshops• Prototipagem
• JAD ( Joint Application Design)• Brainstorming
Escolhendo a técnica
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 146/338
• Deve-se selecionar as técnicas a seremutilizadas e estabelecer a maneira comoelas serão integradas
• A escolha das técnicas e seu esquema de
integração dependerá do problema e daequipe participante• É interessante conhecê-las e saber
identificar onde uma técnica se aplica
melhor que outra
Técnicas específicas deelicitação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 147/338
elicitação
Entrevistas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 148/338
• O Engenheiro de requisitos ou analistadiscute o sistema com diferentesstakeholders e obtêm um entendimentodos requisitos
• Vantagens: contato direto com o usuárioe validação imediata• Desvantagens: conhecimento tácito e
diferenças de cultura
Entrevistas - tipos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 149/338
• Entrevistas fechadas: o analista buscarespostas a um conjunto de questõespré-definidas
• Entrevistas abertas: Não há uma agenda
pré-definida e o engenheiro de requisitosdiscute de forma aberta, o que ostakeholder quer do sistema
• Tutorial: o cliente dá uma aulaexplicando seu trabalho
Entrevistas - dicas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 150/338
• Identificar candidatos• Preparação da entrevista : agendar
e preparar questionário (se for ocaso)
• O analista não deve ir para aentrevistas com noções pré-concebidas
Entrevistas - condução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 151/338
• Informar aos stakeholders o ponto inicial
da discussão. Isto pode ser uma questão,uma proposta de requisitos ou umsistema existente
• Esperar por respostas incompletas
• Repetir frases do entrevistado com suaspróprias palavras• Entrevistadores devem estar cientes da
política organizacional - muitos requisitosreais podem não ser discutidos devido aimplicações políticas
Entrevistas - finalização
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 152/338
• Tempo para rever respostas de todas asperguntas - consolidar informações
• Agradecimentos
• Gerar documento que deve ser assinadopelo entrevistado
Leitura de Documentos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 153/338
• Abstrações• Vocabulário da aplicação
• Vantagens: facilidade de acesso evolume de informações• Desvantagens: dispersão das
informações e volume de trabalho
Questionários
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 154/338
• Quando existe conhecimento sobre o
problema e grande número de clientes• Quando dados estatísticos são
importantes
• Dão idéia definida sobre como certosaspectos do universo de informação sãopercebidos
• Vantagens: padronização das perguntas
e tratamento estatístico das respostas• Desvantagens: limitação do universo de
respostas e pouca iteração
Cenários
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 155/338
• Cenários são partes inerentes de alguns
métodos de desenvolvimento OO• São estórias que explicam como um
sistema poderá ser utilizado. Devem
incluir:– descrição do estado do sistema antes decomeçar o cenário
– o fluxo normal de eventos do cenário
– exceções ao fluxo normal de eventos– informações sobre atividades concorrentes– uma descrição do estado do sistema no final
do cenário
Cenários
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 156/338
• Cenários são exemplos de interação quedescrevem como o usuário interage como sistema
• A descoberta de cenários expõe
interações possíveis do sistema e revelaas facilidades que o sistema podeprecisar
Análise de protocolosETNOGRAFIA
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 157/338
• Analisar o trabalho de determinada
pessoa através da verbalização• Objetivo: estabelecer a racionalidade
utilizada na execução de tarefas
• Vantagens: possibilidade de elicitarfatos não facilmente observáveis epermitir melhor entendimento dos fatos
• Desvantagens: desempenho doentrevistado e “o que se diz é diferentesdo que se faz”
Participação ativa dosusuários
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 158/338
• Incorporação dos usuários ao grupo de
ER• Os usuários precisam aprender a
linguagem de modelagem utilizadas paraler as descrições e criticá-las
• Integração dos usuários na modelagemdo sistema
• Vantagens: envolvimento dos
clientes/usuários• Desvantagens: Tempo em treinamento
dos usuários e falsas expectativas no
usuário
JAD Joint Application Design)• Técnica para promover cooperação,
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 159/338
entendimento e trabalho em grupo entre os
usuários desenvolvedores.• O JAD facilita a criação de uma visão
compartilhada do que o produto de
software deve ser• Através da sua utilização osdesenvolvedores ajudam os usuários aformular problemas e explorar soluções.
Dessa forma, os usuários ganham umsentimento de envolvimento, posse eresponsabilidade com o sucesso doproduto.
• Brainstorming• Brainstorming é uma técnica para
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 160/338
Brainstorming é uma técnica para
geração de idéias. Ela consiste emuma ou várias reuniões quepermitem que as pessoas sugiram eexplorem idéias.
• as idéias são encorajadas, pois elasfrequentemente estimulam osparticipantes, o que pode levar a
soluções criativas para o problema.
Brainstorming• Produza o maior número de idéias
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 161/338
possíveis.Regras do Brainstorming
Esclareça o objetivo da sessão. Gere o maior número de idéiaspossíveis. Deixe a imaginação voar. Não permita críticas ou
debates. Mescle idéias.
Brainstorming: Vantagense Desvantagens
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 162/338
e Desvantagens
• Vantagens–Usado a qualquer tempo, em qualquer
lugar.–
Bom para grupos.–Bom para coisas de alto-nível epressuposições.
–Bom para algum nível de automação.
• Desvantagens–Se aplica mais a processos em grupo.–Não sistemática na forma “clássica”.
Redução de Idéias: Podar eorganizar
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 163/338
organizar
Afine Diagramas
Redução de Idéias: PriorizeIdéias• Priorize idéias restantes.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 164/338
Priorize idéias restantes.
–Vote• Votos cumulativos– Compre idéias
• Voto único
–Aplique avaliações– Critério
• Não ponderado
• Ponderado
Rational University “bucks”
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 165/338
Análise de Requisitos
(Como?)
Análise de Requisitos• Análise - Derivar maiores detalhes dos
R i it d Alt Ní l
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 166/338
Requisitos de Alto Nível.
• Processo iterativo que envolve a compreensãodo domínio, coleta, classificação, estruturação,priorização, validação dos requisitos.
Criar múltiplas visões dos requisitos tais comoprotótipos.
Modelos gráficos de análise e testes.Negociar prioridades.Procurar as funcionalidades escondidas.Fazer avaliações técnicas.
Avaliar riscosDescobrir quais as formas de um fracasso.
Análise de Requisitos -Objetivo• Consiste em organizar os requisitos em
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 167/338
Consiste em organizar os requisitos em
categorias relacionadas.• Examinar o relacionamento e adependênciaentre os requisitos.
• Analisar a consistência, omissões,ambiguidades dos requisitos fornecidospelo cliente.
• Estabelecer uma ordem de prioridadedosrequisitos.
• Reconher a origem e a necessidade decadarequisito.
Análise de Requisitos -Processo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 168/338
Entendimentodo domínio
Coleta derequisitos
Classificação
Resoluçãode conflito
Atrib. PrioridadeEntrada doprocesso
Análise de Requisitos -Checklist• Cada requisito está consistente com o
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 169/338
Cada requisito está consistente com oobjetivogeral do sistema ?
• Os requisitos foram descritos num nívelapropriado de abstração?
• Todos os requisitos são realmentenecessários ?• Quais requisitos podem ser testados e
implementados ?
• Quem solicitou cada requisito ?• Os requisitos foram classificados?• Os requisitos foram priorizados?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 170/338
Análise de Requisitos -Dificuldades
• Stakeholders em geral não sabem o que
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 171/338
Stakeholders em geral não sabem o que
querem• Stakeholders expressam requisitos emsua terminologia
• Stakeholders diferentes podem gerar
requisitos conflitantes• Fatores políticos e organizacionais
podem influenciar os requisitos dosistema
• Requisitos mudam durante o processode análise. Stakeholders novos podemsurgir e o ambiente de trabalho muda
Atividades de Análise
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 172/338
1. Reconhecimento do Problema2. Avaliação do problema e síntese
da solução (Modelagem)
3. Especificação dos requisitos dosoftware
4. Revisão
Atividade 1Reconhecimento do
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 173/338
Problema• A meta é o reconhecimento dos elementosbásicos do problema, conforme percebidos pelocliente.
clientes
Administrador do projeto
analista desenvolvedores
Plano de projetode software
protótipo
Atividade 2Avaliação do Problema e Síntese da
Solução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 174/338
Solução
• Avaliar os problemas na situação atual• Principal Foco para o novo sistema: O
QUE e não COMO:- qual o fluxo e o conteúdo de informação- quais as funções do sistema- quais dados que o sistema produz e consome
- qual o comportamento do sistema
- qual as características de interface- quais são as restrições do projeto
Atividade 2Avaliação do Problema e Síntese da
Solução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 175/338
Solução
• Sintetizar uma ou mais soluções (dentrodo alcance delineado no Plano de Projeto doSoftware)
• O processo de avaliação e síntese continua atéque o analista e o cliente concordem que osoftware pode ser adequadamenteespecificado.
É a maior área de esforço
Atividade 2Avaliação do Problema e Síntese da
Solução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 176/338
Solução
• Durante a atividade de avaliação e síntesedevem ser criados modelos do sistema para secompreender melhor o fluxo de dados e decontrole, o processamento funcional e aoperação comportamental, além do conteúdoda informação.
• O modelo serve como fundamento para oprojeto de software e como base para a criação
de sua especificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 177/338
Atividade 4Revisões
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 178/338
•Devem ser efetuadas revisões técnicas erevisões no Plano de Projeto de Software
as revisões são conduzidas pelo Cliente epelo Analista
a base para a revisão são os documentosproduzidos na Especificação dos Requisitos• O Plano de Projeto do Software deve ser revisto
devido ao conhecimento adquirido durante aanálise.
Atividade 4Revisões
O i t t ti
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 179/338
• Os revisores tentam garantir que a
especificação seja completa, consistentee precisa.
• Respondem a Questões como:
– Metas e objetivos do software permanecemconsistentes com metas e objetivos dosistema?
– O fluxo e a estrutura de informação sãoadequadamente definidas para o domínio da
informação?– Os diagramas são claros?
Atividade 4Revisões
• As funções importantes permanecem dentro do escopo e
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 180/338
As funções importantes permanecem dentro do escopo ecada uma foi adequadamente descrita?
• As restrições de projeto são realísticas? Qual é o riscotecnológico desenvolvimento? Requisitos de softwarealternativos foram considerados?
• Critérios de Validação foram declarados detalhadamente?Eles são adequados para descrever um sistema bemsucedido?
• Existem inconsistências, omissões ou redundâncias?
• O usuário revisou o Manual Preliminar ou o protótipo?
• Como as estimativas do Plano de projeto de Softwareforam afetadas?
Revisar as Especificaçõesdo Cliente
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 181/338
• Identificar Requisitos.–Reconhecer e rotular:
• Comportamentos da Aplicação
• Atributos comportamentais• Questões e Suposições
• Perguntar ao cliente.
Revisão dosRequisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 182/338
Especificação de Requisitos
(Escrever)
Princípios de uma boaespecificação
1 Separe funcionalidade de implementação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 183/338
1. Separe funcionalidade de implementação
2. A especificação deve abranger o sistema doqual o software é um componente3. Uma especificação deve abranger o ambiente
no qual o sistema opera4. Uma especificação de sistema deve ser um
modelo cognitivo5. Uma especificação deve ser operacional6. A especificação do sistema deve ser tolerante
com não ser completa e ser expansível7. Uma especificação deve ser localizada e
fracamente acoplada.
Especificação
D t f li
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 184/338
• Documentar e formalizar osresultados da elicitação e daanálise.
• Usar templates específicos dedocumentos para cada tipo derequisito.
d ifi ã d i i
Princípios de uma boaEspecificação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 185/338
• Formato da Especificação de Requisitos1. Introdução - declara as metas e os objetivos do
software, descrevendo-os no contexto dosistema baseado em computador
2. Descrição da Informação - descrição detalhadado problema que o software deve resolver
3. Descrição Funcional
4. Descrição Comportamental
5. Critérios de Validação6. Bibliografia
7. Apêndice
Especificação• Registrar os vários tipos de informações
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 186/338
g p ç
dos requisitos para facilitar acomunicação entre os stakeholders doProjeto.
Documentações em linguagem natural.
Modelos gráficos de análiseArmazenar as informações dos requisitosFerramentas de gerenciamento comercial Utilizando documentos padrões
Documento de Requisitos• Introdução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 187/338
ç
• Definição dos Requisitos do Usuário• Especificação dos Requisitos do
Sistema
• Modelo do Sistema• Arquitetura do Sistema• Glossário• Apêndices
Importância daEspecificação Correta
• Uma compreensão completa dos Requisitos do
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 188/338
• Uma compreensão completa dos Requisitos do
Software é fundamental para obter umsoftware e um processo de desenvolvimentocom alta qualidade
• Não importa quão bem projetado ou codificadoestá um programa, se ele for mal analisado eespecificado desapontará o usuário e traráaborrecimentos ao desenvolvedor
• Reduz o custo e o retrabalho
• Referência para Validação Final• Base de Concordância Cliente e Fornecedor
Documento por Tipo deRequisito
Funcional Não-funcional
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 189/338
Requisitos de
negócio
Requisitos deusuário
Regras denegócio
Atributos de
qualidade
Interfacesexternas
RestriçõesRequisitosfuncionais
Requisitos desistema
Documento de visão eescopo
Documento de casode uso
Especificação dosrequisitos de software
Quais artefatos são usadosOnde o problema é definido?Onde os stakeholders e usuários são listados?Onde os ambientes e plataformas são
Visão
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 190/338
Onde os ambientes e plataformas são
identificadas?
Onde os casos de uso são
mantidos?
Onde o vocabulário comum está descrito?
Especificações
de Caso de uso
Glossário
EspecificaçãoSuplementar
Onde os requisitos não funcionaisestão localizados?
Onde as Necessidades eRequisiçõesdos stakeholders são capturadas?
Requisições do
Stakeholder
Descrever Stakeholders no Documento deVisãoStakeholder
Digitador
Representante Kelly Hansen
Descrição Usuário
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 191/338
Tipo O digitador é tipicamente um técnico com conhecimentos em
informática. O digitador é treinado e experiente no uso do atualsistema batch de registro.
Responsabilidades O digitador é responsável por administrar o cadastro de cursos paracada per íodo letivo. Isto inclui a supervisão administrativa e de permissão de acesso aos dados.
Critério de Sucesso Conseguir manter o banco de dados de estudantes e professores, eabrir/fechar cursos para matr ícula.
Envolvimento A responsabilidade primária dos digitadores ser á manter o bancode dados de estudantes e professores, e abrir/fechar cursos paramatr ícula.
Também ser á requerido da área de matr ículas….
Entregas Gestor de Revisão – especialmente nas funcionalidades requisitadas pela área de Matr ículas.
Comentários/Preocupações
Nenhum
Descrever o problema no Documento de Visão
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 192/338
Especificações deManual doUsuário
Especificações deDesign
Requisiçõe
s doStakeholder
Documento deVisão
Especificação
Suplementar
Modelo de
Caso de Uso
Definição doProblema
Documento de Visão
• As mesmas informações para gerência,
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 193/338
As mesmas informações para gerência,
marketing, e equipe de projeto.• Fornece o feedback inicial do cliente.• Promove uma compreensão única do
produto.• Define escopo e prioridade em alto-nível das requisições do stakeholder esuas características.
• Um documento de sistema quedescreve o “que” e “porquê” doproduto.
Visão
Estrutura do Documento deVisão1. Introdução
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 194/338
ç
2. Posicionamento3. Descrições do Stakeholder e Usuário4. Visão Geral do Produto5. Características do Produto
6. Restrições7. Faixas de Qualidade8. Precedência e Prioridade9. Outros Requisitos do Produto10. Requisitos de Documentação11. Anexo 1 – Atributos das Características
Obtendo o Entendimento doProblema
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 195/338
Descrição do Problema
Visão
O problema de (descreva o problema)
afeta (os stakeholders afetados peloproblema)
O impactodisto é que
(qual o impacto do problema)
Uma solução desucesso seria
(listar vários benefícios-chave denegócio para uma solução de sucesso)
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 196/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 197/338
Definir a fronteira da solução desistema
Outros
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 198/338
ã
Comunicações Relatórios
Novo Sistema
Outros
sistemas
UsuáriosSistemasLegados
Atores ajudam a definir afronteira do sistema
Fronteira do
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 199/338
PC
Fronteira do
sistema?
ServidorPC
PC
PC
Quem é o ator? Os módulos dosistema ou o usuário?
Servidor
PC
Capturando o Vocabulário comumdo sistema
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 200/338
• Definir os termos usados no projeto.
• Ajudar a previnir mal-entendidos.
Glossário
Capturar o Vocabulário Comum
•Começar o mais cedo
possível.•Continua durante todo o
projeto.
Conceitos de Modelagem deCasos de Uso
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 201/338
• Um ator representa uma pessoa ououtro sistema que se comunicacom o sistema
• Um caso de uso define umaseqüência de ações que o sistemarealiza para entregar algo de valor
ao atorActor Use Case
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 202/338
Um usuário pode agir comovários atores
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 203/338
Charlie comoGerente
CharlieEngenheiro
Gerente
Engenheiro
Charlie
Caso de Uso
Use Case
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 204/338
• Especifica um diálogo entre ator esistema
• O caso de uso é iniciado por um ator
que invoca uma funcionalidade dosistema
• Um caso de uso é completo e com
um conjunto de fluxos entendível• Todos juntos, os casos de usorepresentam as diversas formas deutilizar o sistema
Use Case
Cenário – Um passo pelo caso deuso
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 205/338
• Um caso de uso pode ter várias instâncias• Um cenário é descrito como uma instância
de caso de uso: uma seqüência específica de
ações que ilustra o comportamento dosistema
Matrícula emCurso
Estudante Funcionário
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 206/338
O que é um modelo de Casode Uso
• Atores e suas descrições
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 207/338
• Diagramas de casos de uso e seusrelacionamentos
• Para cada caso de uso:
– Nome e descrição breve– Da especificação textual:• Fluxo de eventos• Pré e pós condições
• Requisitos especiais• Outros diagramas (estado, seqüência, atividades,
classes e etc)
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 208/338
O que é modelagem de casosde uso?• Associe necessidades a requisitos de
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 209/338
Associe necessidades a requisitos de
software.• Defina claramente as fronteiras do
sistema.• Capture e comunique o comportamento
que é desejado do sistema.• Identifique quem ou o que interage
com o sistema.
• Valide/Verifique requisitos.• É um instrumento de
Planejamento.EspecificaçãoCaso de Uso 2
Ator 2
Use case 1
Modelo
Use case 2
Use case 3
Use case 1
Modelo de Caso de Uso
V lt l M d l d CSU
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 210/338
Use case 2
Use case 3
Volta pelo Modelo de CSU- Navegue pelos textos- Liste todos os atores- Liste todos os casos de uso
Especif. CSU 2- Descrição Breve- Fluxo de eventos
Espec. CSU 3- Descrição breve- Fluxo de eventos
Ator 1Ator
Ator 3
Especificação CSU 1- Descrição breve- Fluxo de eventos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 211/338
O que é um Caso de Uso?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 212/338
Define a seqüência de ações
Realizado pelo sistema
Que produz um resultado de valorPara um ator.
Um Casode Uso
Nome do Caso de Uso
O Caso de Uso contém osRequisitos de Software
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 213/338
• Cada caso de uso– Descreve ações no sistema que entrega algo
de valor para um ator.– Apresenta a funcionalidade do sistema
usada pelo ator– Modela o diálogo entre sistema e ator.– É um fluxo de eventos completo e
significativo dos eventos da perspectiva deum ator em particular
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 214/338
Ciclo de Vida de Casos de Uso
DescobertFechar Matrículas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 215/338
o
Rabiscado
Descrevabrevement
e
Descrição Breve: Este caso de uso permite aoDigitador fechar o processo de matrículas. Ofertas decurso que não possuírem alunos serão canceladas. Osistema de Cobrança é notificado com todos os dados dematrícula para assim efetuar as devidas cobranças.
Resumo do Fechar Matrículas-Fluxo de Eventos
-Passo-a-Passo
Fechar Matrículas Especificação de Caso deUso- Fluxo de Eventos detalhadoRequisitos Especiais-Condições Pré/Pós
Totalmente Descrito
Definir Atores: Foco nos papéis• Um ator representa
um papel que um
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 216/338
um papel que um
humano, hardware,ou outro sistemadesempenha emrelação ao sistema.
• Os nomes de atordevem representarclaramente seupapel.
?
Atores e Papéis
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 217/338
Charlie e Jodie agemcomo estudantes.
Charlie também agecomo Professor.
Estudante
Professor
Matricularem Curso
Submeter grades
Charlie: Está empregado comoprofessor de matemática e é
aluno de Economia.
Jodie: É um aluno deCiências.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 218/338
Convenções das setas e linhas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 219/338
Supervisor Sensor ativo
Sensor passivo
Sensorhíbrido
Supervisor
Monitorar
Alarmes
Sensor passivo
Sensor
Sensor ativo
Monitorar
Alarmes
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 220/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 221/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 222/338
Exemplo: Sistema de Matrículas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 223/338
Sistema de Registrode Cursos
Estudante
Sistema de Matrículas
Ator XAtor Y
Matricular em Curso
Outro caso de uso
Caso de Uso 3
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 224/338
Passos para criar o Modelo deCasos de Uso
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 225/338
1. Procurar atores e casos de uso.
– Identifique e descreva brevemente os atores.
– Identifique e descreva brevemente casos de usos.
1. Escreva os casos de uso.
– Desenhe todos os casos de uso.
– Priorize os fluxos de casos de uso.
– Detalhe os fluxos por ordem de prioridade.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 226/338
Identifique atores
• Quem/o que usa o sistema?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 227/338
• Quem/o que obtêm informação dosistema?• Quem/o que fornece informação
para o cliente?• Onde na empresa o sistema éusado?
• Quem/o que suporta ou mantêm osistema?
• Quais outros sistemas usam osistema?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 228/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 229/338
Identificar Casos de Uso
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 230/338
Ator
Objetivo 1
Objetivo 2
Quais objetivosdesejo alcançarutilizando o
sistema?
Identifique os Casos de Uso
• Quais são os objetivos de cada
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 231/338
ator?–Porque o ator quer utilizar o sistema?–O ator irá criar, guardar, mudar,
remover, ou ler dados no sistema? Sesim, porque?–O ator precisa informar ao sistema
sobre mudanças ou eventos externos?
–O ator precisará ser informado sobrecertas circunstâncias do sistema?
• O sistema atende ao negócio com
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 232/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 233/338
Decomposição funcional• É a quebra do problema em partes
menores, isoladas.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 234/338
–As partes juntas fornecem afuncionalidade do sistema.•Muitas vezes não fazem sentido se isoladas.
• Casos de uso:–Não há decomposição funcional.–Mantêm a funcionalidade junta para
descrever o uso completo do sistema.–Fornecer o contexto.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 235/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 236/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 237/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 238/338
Como represento as exceções ?
Cenários Alternativos
Cenário Principal e oCenário Alternativo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 239/338
Alternativa: Problemas na leitura do cartãomagnético
1ª) Se o sistema não conseguir ler o dados do cartão , tentarnova lleitura por no máximo duas vezes. Caso persista o
problemas encerrar o caso de uso.
Alternativa: Senha inválida
3ª) Se a senha digitada não for igual à igual a senhacadastrada , informar e solicitar nova digitação .Esteprocedimento pode ser repetido no máximo 3 tentativas. Apósa terceira tentativa a conta do usuário deve ser bloqueada e ocaso de uso encerrado. Include Bloquear conta
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 240/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 241/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 242/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 243/338
Associação (Association)
Relacionamento entreCasos de Uso e Atores
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 244/338
Interação do ator com o caso de uso por meio do envio erecebimento de mensagens.
binárias -> envolvem apenas dois elementos.
Por exemplo: O ator Correntista envia e recebe mensagensdo Caso de Uso Calcular Empréstimo Pessoal, por um
relacionamento de associação.
Generalização (Generalization)
Relacionamento entreCasos de Uso e Atores
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 245/338
Ocorre entre Casos de uso OU entre atores
Dois elementos semelhantes, mas com um deles realizando
algo mais.
Por exemplo:podemos criar um ator genérico
Aluno e especializá-lo nos atores Aluno Matriculado eAluno Ouvinte
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 246/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 247/338
Relacionamento entreCasos de Uso e Atores
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 248/338
Atendimento ao cliente
Mostrar Mapa do
salão
Reserva de
Restaurante
Cadastrar Cliente
Reserva
«extends»
include«uses»
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 249/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 250/338
Modelando casos de uso como auxílio de pacotes
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 251/338
• Impossível representar vários casos de uso em umúnico diagrama é uma tarefa impossível
• Podemos agrupar casos de uso considerando uma
mesma abordagem conceitual, podemos trabalharcom pacotes • Agrupamento de qualquer elemento de modelo, como
casos de uso, classe, estados, outros pacotes etc..
Nomenclatura <nome do pacote>seguido de :: e
<nome do elemento> pacote::elemento Exemplo: Controle Acadêmico::Cadastrar Aluno
Protótipos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 252/338
• Armas importantes no processo dedesenvolvimento
• Interface gráfica – RAD(Rapid Application
Development)• Validação do usuário• Pedir padrões gráficos distintos• Levantar detalhes que não foram vistos
Evoluir o Caso de Uso
E t d t
Sistema de
M t í l C
Matricularem Curso
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 253/338
Especificação de Caso deUso
do Matricular para Curso+ Fluxo de Eventos detalhado
• Passo a Passo+ Requisitos Especiais+ Condições Pré/Pós
Matricular Online em Curso+ Fluxo de eventos rabiscado
• Passos de alto nível
Estudante Matrícula em Curso+ Descrição Breve
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 254/338
Validação• É o processo de verificar os requisitos
quanto a sua validade, consistência,
l li f ilid d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 255/338
completeza, realismo e sua facilidadede verificação.
• Se os requisitos demonstram o quecliente realmente quer.
Verificações• Validade.
– O sistema fornece as melhores funções
t d id d d li t ?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 256/338
para atender as necessidades de cliente?Soluções conciliatórias com os usuáriosfunções adicionais ou diferentes que sãoexigidas.
• Consistência.– Existem requisitos em conflito ? Descrições
diferentes para uma mesma função do
sistema ou restrições contraditórias.
Verificações• Completeza.
– Todas as funções solicitadas e exigidas
l li t tã i l íd ?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 257/338
pelo cliente estão incluídas?
• Realismo.– Os requisitos implementados estão dentro
do orçamento, prazo e da tecnologiaexistente?
• Facilidade de Verificação.– Os requisitos podem ser verificados?
Como é o Processo
Cliente
Requisitos Ad-hoc vindos de um cliente Membrodo Projeto
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 258/338
Aprovado pelo Cliente
Especificação corrigida
Rejeitada Novamente
Especificação corrigida
Rejeitado pelo cliente
Especificação de RequisitosCliente
Técnicas de Validação• Revisões de Requisitos
– Requisitos analisados sistemáticamente por
i d i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 259/338
uma equipe de revisores.
• Prototipação– Um modelo executável do sistema é
mostrado aos usuários finais e clientes.Podem experimentar o modelo para verificarse ele atende às suas necessidades.
Técnicas de Validação• Geração de Casos de Teste
– Como modelo ideal os requisitos deveriam
t tá i S t t i it
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 260/338
ser testáveis.Se os testes para os requisitossão criados como parte do processo devalidação isso muitas vezes revelaproblemas nos requisitos.
• Análise Automatizada da consistência.– Se os requisitos são expressos como modelo
de sistema em uma notação formal ou
estruturada então pode-se utilizar umaferramenta CASE para verificar aconsistência do sistema.
Revisão dos Requisitos• Revisões regulares devem ser feitas
regularmente enquanto os requisitos estão
d f l d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 261/338
sendo formulados.
• Ambos, cliente e a equipe do contratantedevem ser envolvidos nas revisões.
• As revisões podem ser formais (com adocumentação concluída) ou informais. Boacomunicação entre colaboradores, clientes
e usuários podem resolver problemas emum estágio bem inicial.
Revisores check• Verificabilidade. da forma como foi definido pode ser
testado?
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 262/338
• Facilidade de Compreensão. O requisito pode seradequadamente compreendido pelo compradores ou usuáriosfinais ?
• Facilidade de Rastreamento. A origem do requisito éclaramente definida ?
• Adaptabilidade. Ele pode ser modificado, sem que isso
provoque efeitos em grande escala em outros requisitos dosistema. Muito impacto?
Dificuldades de Validação• Conflitos, contradições, erros e omissões
devem ser destacados durante a revisão.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 263/338
• Devem ser formalmente registrados.
• Fica por conta dos usuários, compradores
e dos desenvolvedores do sistemanegociar a solução para esses problemasidentificados.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 264/338
Processo Unificado
Visão Geral dos Conceitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 265/338
Uma abordagem iterativaEm uma
iteração,
você passat d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 266/338
Disciplinasagrupam
atividadeslogicamente.
você passapor todas as
disciplinas.
Conteúdo do RUP - Fases• O conteúdo do RUP é organizado em
disciplinas
• Uma disciplina é um conjunto de tarefasrelacionadas a uma área de interesse
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 267/338
• Uma disciplina é um conjunto de tarefasrelacionadas a uma área de interesse• Disciplinas do RUP:
– Requisitos– Modelagem de Negócio– Gerência de Configuração & Mudanças– Ambiente– Gerência de Projetos– Análise & Design
– Implementação– Teste– Implantação
Disciplinas
RUP temdi i li
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 268/338
RUP temdisciplinas.
Artefatos são desenvolvidos em
cada disciplina através de um
processo iterativo.
Disciplinas produzem e compartilhammodelos
Várias disciplinasproduzem modelos
Análise & DesignRequisitosModelagemNegócio Implementação
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 269/338
produzem modelos… DesignNegócio ção
Implementado
por
Modelo deImplementação
Modelo deDesign
Modelo de
Caso de Uso
Modelo de
Negócio
BusinessAnalysis Model
RealizadoPor
Automatizado por
Realizado por
Teste
Verificado por Validado por
BBB
B
…cada modelo éaveriguado.
E n t r e g a
Entrada para
Papéis e artefatos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 270/338
Fonte: IBM Rational Unified Process
Quem deve usar o RUP?
• O RUP pode te ajudar a entregar edesenvolver software críticos para
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 271/338
desenvolver software críticos parao sucesso de sua empresa
• O RUP foi pensado primariamente
para dois grupos de usuário:– Participantes de uma equipe de
desenvolvimento de software,inclusive os stakeholders
– Engenheiros de Processo,principalmente de software eGerentes de Software
Por que eu devo utilizar oRUP?
• RUP lhe fornece um processo de software
baseado em padrões customizável e
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 272/338
baseado em padrões, customizável econfigurável– Permite publicar um processo customizável e
acessível para qualquer um
– Permite customizar o processo para cada Projeto– Fornece uma visão filtrada para cada tipo de
função (Visão para Analistas, Gerentes e etc)
• O RUP é formado por boas práticas deEngenharia de Software melhoradocontinuamente para refletir as mudanças daIndústria de Software
Por que devo utilizar o RUP(cont.)
• Para stakeholders:
– Fornece um glossário de termos e umai l édi d h i t lh j d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 273/338
– Fornece um glossário de termos e umaenciclopédia de conhecimentos que lhe ajudam acomunicar suas necessidades à equipe dedesenvolvimento
• Para integrantes da equipe– O RUP apresenta uma função central e comum
de definição de processo que os membros podemcompartilhar para melhorar a comunicação.
• Para gerentes e gerentes de projeto–
Fornece um meio de comunicação efetivo com aequipe, ajudando da gerência, planejamento econtrole
• Para Engenheiros de Processo– Fornece uma base de conhecimento, conteúdo e
Quando usar o RUP?O RUP pode ser usado desde o início até as fases de manutenção doprojeto. O RUP pode ser customizado para suas necessidades, masseguindo as considerações abaixo:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 274/338
• Ciclo de Vida do Software(nº de iterações, tamanho dasfases e do projeto)
• Objetivos de negócio doprojeto, visão, escopo e risco
• Tamanho e complexidadedo esforço de
desenvolvimento
Sintomas e Causas-Raiz
• Quais os sintomas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 275/338
• Quais os sintomasde problemas nodesenvolvimentodos softwares?
• Quais as causas-raiz de cada
sintoma?
Sintomas dos Problemas deDesenvolvimento de Software• Necessidades dos
usuários não atendidas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 276/338
usuários não atendidas• Confusão de Requisitos• Módulos não integram• Difícil de Manter
• Descoberta tardia defalhas
• Qualidade e iteratividadebaixa
• Performance baixa• Equipe não coordenada• Problemas de build e
Relação Problema-Causa
Não atende Requisitos
Sintoma Causas Raiz Princípio-Chave
Adaptar o Processo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 277/338
necessid.
ConfusãoRequisitos
Modules don’t fit
Difícil Manter
Descoberta tardia
Qualidade baixa
Performancebaixa
Time colide
Build-e-release
qinsuficientes
Comunicação ambígua
Conflitos arquiteturais
Alta complexidade
Inconsistênciasescondidas
Pouco teste
Avaliação subjetiva
DesenvolvimentoCascata
Mudanças nãocontroladas
Automação
ComunicaçãoAmbígua
Inconsistênciasescondidas
Módulos nãointegram
Adaptar o Processo
Balancear requisiçõesdos Stakeholders
Demonstrar ValorIterativamente
Elevar Abstração
Colaboração no time
Focar qualidadecontinuamente
Princípios-Chave para oDesenvolvimento Orientado a
NegóciosA Adapt The Process
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 278/338
Negócios
F
E D
C
B
A Adapt The ProcessBalance Competing StakeholderPriorities
Collaborate Across TeamsDemonstrate Value IterativelyElevate Level Of AbstractionFocus Continuously On Quality
Principio: Adaptar oProcessoA
É adaptar o processo ao tamanho do projeto. A quantidade decerimônia, precisão e controle apresentada pelo projeto deve serde acordo com o tamanho da equipe, se estão locais ou remotas,
fase do projeto e quantidade de restrições do mesmo.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 279/338
• Benefícios– Eficiência de Ciclo de Vida– Comunicação honesta e aberta dos riscos
• Padrão– Tamanho certo do processo para o processo
– Adaptar a cerimônia do processo a fase do ciclode vida e permitir a cerimônia as circunstânciasdo projeto
– Melhorar o processo continuamente– Balancear lanos e estimativas ao nível de
p j q ç
Tamanho certo do processoas necessidades do projeto
• Mais processo não é necessariamente
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 280/338
• Mais processo não é necessariamentemelhor
• Para projetos menores com o time todos
juntos localmente e tecnologia conhecida,o processo deve ser menor• A medida que o projeto cresce, é
necessário um processo mais disciplinado
Fatores que afetam o tamanho doprocesso
• Vários fatores afetam o tamanho doprocesso:
Tamanho do projeto
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 281/338
– Tamanho do projeto– Distribuição geográfica da equipe– Complexidade tecnológica
– Número de stakeholders– A fase do projeto
Princípio: Balancear Prioridadesconcorrentes do Stakeholder
• É importante balancear porque:F t t há flit d ó i d
B
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 282/338
É importante balancear porque:– Frequentemente há conflitos de negócio e denecessidades
– Questão de desenvolvimento customizado Xpacotes prontos
• Benefícios– Alinhar a aplicação com o negócio e
necessidades– Reduzir desenvolvimento customizado
– Otimizar o valor do negócio• Padrões– Definir, entender e priorizar o negócio e
necessidades– Priorizar ro etos e re uisitos e relacionar
B
Balancear necessidade de negócio ede usuário
• Gerenciar Requisitos efetivamente–
Capturar processos de negócioPriorizar projetos e capacidades do sistema para
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 283/338
Capturar processos de negócio– Priorizar projetos e capacidades do sistema parasuportar necessidades de negócio
• Atualizar prioridades quando o
entendimento do projeto cresce– Envolve o usuário para garantir o entendimento
das necessidades, usando:• Desenvolvimento orientado a casos de uso
• Design centrado no usuário• Use soluções de pacote e itens existentes
para entregar mais rápido e com customenor
Entender quais itensabsolver
• Entender quais itens estão
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 284/338
Entender quais itens estãodisponíveis e balancear reuso deitens com necessidades
• Exemplos de itens:– Aplicações Legadas– Serviços– Componentes Reutilizáveis
– Padrões
Princípio: Colaborar pelotime
C Prioriza comunicação otimizada no projeto. Alcançado comorganização do time e ambientes colaborativos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 285/338
• Benefícios– Produtividade do time– Melhor relacionamento entre necessidades do negócio e o
desenvolvimento e operação de sistemas de software• Padrões– Motivar pessoas para realizar o seu melhor– Criar times auto gerenciáveis– Encorajar colaboração pelas funções (analistas, gerentes,
etc)– Fornecer ambiente colaborativos– Gerenciar o desenvolvimento de artefatos e tarefas para
melhorar a colaboração– Integrar negócio, software e atividades do time
Princípio: Demonstrar valoriterativamente
B fí i
DO processo iterativo possibilita acomodar mudanças, obterfeedback e reduzir riscos cedo
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 286/338
• Benefícios– Cedo de riscos cedo– Previsibilidade alta no projeto
– Confiança junto aos stakeholders• Padrões
– Possibilita feedback ao entregar valor
iterativamente– Adaptar seus planos usando o processo iterativo– Abraçar e gerenciar as mudanças– Atacar os maiores riscos técnicos, negociais e
Habilitar feedback Entregandovalor iterativamente
• Divida o projeto em iterações
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 287/338
Divida o projeto em iterações– Cada iteração realizará vários requisitos,
design, implementação, teste daaplicação, produzindo um executávelpara o usuário
• Obter feedback dos stakeholderspara:
– Ver se estamos movendo na direçãocerta?– Stakeholders satisfeitos?– Precisamos alterar características á
Adaptar seus Planos ao ProcessoIterativo
• Desenvolvimento iterativo fornece um
bom entendimento de:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 288/338
bom entendimento de:– Onde estamos?– Em qual velocidade o time está?
– Precisamos fazer correções no curso paracompletar o projeto com sucesso
• Podemos usar esta informação para:
– Atualizar o plano para o projeto– Desenvolver planos detalhados para a
próxima iteração
Abraçe e Gerencie a Mudança
• As aplicações são muito complexasi it d i
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 289/338
As aplicações são muito complexaspara que requisitos, design,implementação e teste funcionem
na primeira vez• Processos efetivos abraçam asmudanças
• O processo iterativo nos fornece aoportunidade de implementarmudanças incrementalmente
Ataque riscos cedo
• A necessidade de atacarriscos cedo não pode ser
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 290/338
A necessidade de atacarriscos cedo não pode sersubestimado. Isto inclui:– Riscos técnicos
– Riscos negociais– Riscos de programação
• Isto é feito avaliandoriscos continuamente,
atacando os maioresriscos nas primeirasiterações.
Perfil dos Riscos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 291/338
Princípio: Elevar o nível deabstração
• Benefícios
E Reduz a complexidade e diminui a quantidade de documentaçãogerada. É alcançado com reuso, uso de modelagem visual earquitetura estabilizada
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 292/338
Benefícios– Produtividade– Complexidade reduzida
• Padrões– Reuso de itens– Use ferramentas de alto-nível e linguagens para
reduzir quantidade de documentação– Foco na arquitetura primeiro– Arquitetura para requisitos não funcionais:
qualidade, flexibilidade e controle dacomplexidade
Reuso de itens existentes• Reduz complexidade de maior impactona produtividade
• Trabalhando com alto nível deabstração reduz se a complexidade e
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 293/338
Trabalhando com alto nível deabstração reduz-se a complexidade efacilita-se a comunicação
• Reduzir complexidade reutilizando:– Componentes reutilizáveis– Sistemas legados– Processos existentes de negócio
– Padrões– Software open-source
Princípio: Foco contínuo naQualidade
F Enfatiza o alcance da qualidade. Um processo iterativo é adaptado
para alcançar qualidade por que oferece várias métricas eoportunidades de correção
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 294/338
• Benefícios
– Alta qualidade– Alcance rápido do progresso e qualidade
• Padrões– Garantir a responsabilidade da equipe na
qualidade do produto– Testar cedo e continuamente com integraçãodas capacidades demonstráveis
– Teste incremental e build contínuo
p ç
Disciplinas de Requisito -Propósitos
• Estabelecer e manter um acordo com osusuários e outros stakeholders sobre o
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 295/338
que o sistema deve fazer• Fornece à equipe um melhor
entendimento dos requisitos do sistema
• Define as fronteiras do sistema (escopo)• Fornece a base para o planejamento das
iterações• Fornece uma base para estimar custo e
tempo• Define a interface visual do sistema
baseado nas necessidades levantadas
Tipos de Requisito
• Características: escopo do projeto– Documentado no Documento de Visão
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 296/338
• Requisitos Funcionais: especificainterações com o usuário
– Documentado nos Casos de Uso• Requisitos Suplementares: especifica
requisitos não funcionais
(performance, segurança e etc), alémde requisitos gerais do sistema, nãoespecíficos de um caso de uso– Especificação Suplementar
Papéis e Artefatos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 297/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 298/338
Análise do Problema:Atividades e Artefatos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 299/338
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 300/338
Gerenciamento de
Requisitos
Gerenciamento de Requisitos• Gerenciamento de requisitos é o
processo de controlar as mudanças dosrequisitos durante o processo daengenharia de requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 301/338
q pengenharia de requisitos.
• Requisitos são inevitavelmenteincompletos e inconsistentes– Requisitos novos surgem durante o processo
de acordo com mudanças nas necessidadesdo negócio e um entendimento melhor dosistema é desenvolvido.
– Diferentes pontos de vista têm diferentesrequisitos e esses geralmente sãocontraditórios.
Gerenciamento de Requisitos• Requisitos são por natureza voláteis. Diversos
fatores contribuem para sua instabilidade ao longodo tempo. Mudanças externas no ambiente(mudanças de legislação, mudanças no mercado,
d i i é i d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 302/338
mudança no posicionamento estratégico daempresa), erros incorridos no processo derequisitos, entre outros. Todos esses fatores fazem
com que seja necessário alterar os requisitos. Taisalterações precisam ser conduzidas de formaordenada para que não se perca controle sobre oprazo e o custo do desenvolvimento.
Gerenciamento de RequisitosOs benefícios desta atividade são percebidos nomédio prazo, sendo que são necessáriosinvestimentos no curto prazo.
Assim, a atividade é, muitas vezes, tida como um
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 303/338
fardo desnecessário à condução do processo.
Contudo, sua não implementação faz com que aseconomias de curto prazo sejam logo suplantadaspelas despesas no longo prazo, verificadas comsuperação de custo e prazo nos projetosconduzidos.
• .
Mudanças nos Requisitos• A prioridade dos Requisitos nosdiferentes pontos de vista mudamdurante o processo de desenvolvimento.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 304/338
• Os donos, clientes do sistema podemespecificar os requisitos em uma
perspectiva do negócio que é diferentedos requisitos do usuário final.
• O negócio e o ambiente técnico dosistema mudam durante o seudesenvolvimento.
Controle de Mudanças
• Checar validade da solicitação de mudança;
• Identificar os requisitos diretamente afetados
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 305/338
com a mudança;• Identificar dependências entre requisitos para
buscar os requisitos afetados indiretamente• Assegurar com solicitante a mudança a serrealizada;
• Estimar custos da mudança;• ·
Controle de Mudanças
• Obter acordo com usuário sobre ocusto da mudança
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 306/338
custo da mudança.• Após a realização desta análise,
podemos aceitar ou rejeitar amudança, conforme os impactos ecustos que ela pode ter no sistema
Controle de Mudanças• O ponto de entrada de qualquer mudança deve
ser a elicitação.
Eli it ã d
Mudança
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 307/338
Elicitação derequisitos
Modelagem deRequisitos
Análisede requisitos
Especificaçãode requisitos
Documento derequisitos
Validaçãode requisitos
Engenharia de Requisitos
Análise deImpacto
Matriz deRastreabilidade
• A matriz de
rastreabilidade fornece oinsumo daanálise deimpacto.
• Toda adocumentação deve ser
revisada.
GERENCIAMENTO DECONFIGURAÇÕES
• O objetivo do Gerenciamento de Configurações(Configuration Management) é estabelecer e
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 308/338
manter a integridade dos produtos de trabalho,utilizando a identificação da configuração,controle da configuração, comunicação do
status da configuração e auditorias deconfigurações. [PA159]
GERENCIAMENTO DE CONFIGURAÇÕESA área de processo de Gerenciamento de Configuraçõesenvolve:
• Identificar a configuração de produtos de trabalhoselecionados que compõem as baselines emd i d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 309/338
determinados momentos no tempo• Controlar as mudanças nos itens de configuração• Construir ou fornecer especificações para construir
produtos de trabalho a partir do sistema degerenciamento de configurações
• Manter a integridade das baselines•
Fornecer um status preciso e os dados atuais deconfigurações para desenvolvedores, usuários finais eclientes
Plano de gerência de configuração
• estabelecer normas, ferramentas e templates quepermitam gerenciar de maneira satisfatória os
itens de configuração de um sistema,d fi id d d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 310/338
• definidos por Pressman como: “cada um doselementos de informação que são criados durante odesenvolvimento de um produto de software, ou
que para este desenvolvimento sejam necessários,que são identificados de maneira única e cuja
evolução é passível de rastreamento”.
Baseline• Em cada fase do processo de
desenvolvimento, um conjunto bem definido
de itens de configuração deve serestabelecido
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 311/338
estabelecido.• A este conjunto é dado o nome de
baselines.
• Estas baselines servem como marco noprocesso de desenvolvimento
• ao final de cada fase é estabelecida umanova baseline e, portanto, todos os itens deconfiguração estão sob total controle deseus desenvolvedores
BaselineÉ guardada “uma foto” dos artefatos criadosaté aquele momento:
•· tornando mais fácil realizarmodificações nos artefatos de maneira
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 312/338
modificações nos artefatos de maneiracontrolada;•· possibilitando ter um controlesistemático sobre todos os itens deconfiguração abordados em cada fase do ciclode vida do software
•· tornando possível que sejamrealizadas, mais facilmente, avaliações sobreseu grau de evolução.•.
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 313/338
Baseline
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 314/338
• O versionamento da documentação é a base para ocontrole através de baselines. Todo artefato deve ter uma
lista de revisões.
Baseline VerticalDocumento de
Requisitos Projeto Teste
Documento
de Usuário
Baseline 1 V1.3 V2.4 V1.0 V2.1
Baseline 2 V1.4 V2.5 V1.5 V2.3
Baselines
X Artefatos
Req1
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 315/338
• Conjunto de artefatos de requisitos e projeto que formauma baseline de entrega ao cliente.
... ... ... ... ... ...
Baseline Horizontal
Baseline X
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 316/338
Baseline X
Versão• As entregas ao cliente devem ser controladas por baselines,para menhor controle de versionamento.
Rastreabilidade• No centro da atividade de gerenciamento
de requisitos está a rastreabilidade.
• Esta é definida como a habilidade de se
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 317/338
• Esta é definida como a habilidade de seacompanhar a vida de um requisito emambas as direções (por exemplo:
partindo de requisitos e chegando aprojeto ou, partindo de projeto echegando a requisitos) do processo desoftware e durante todo o seu ciclo de
vida.
Rastreabilidade• Responsável por dependências entre
requisitos, suas origens e projeto do
sistema
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 318/338
• É base do gerenciamento de requisitos edo processo de controle de mudanças
Rastreabilidade• A dificuldade envolvida com a
rastreabilidade está no grande volume de
informações gerado.• As informações do processo de requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 319/338
As informações do processo de requisitosdevem ser catalogadas e associadas aosoutros elementos de forma que possam
ser referenciadas através dos diversositens de informação registrados.• É um trabalho extenso que, sem o auxílio
de ferramentas adequadas, muito
provavelmente não poderá ser feito
Rastreabilidade• Para implementar a rastreabilidade,
usualmente é confeccionado em conjuntocom a especificação de requisitos um
t f t h d t i d
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 320/338
artefato chamado matriz derastreabilidade, que tem como objetivo
mapear os rastros dos requisitos descritosna especificação.
RastreabilidadeOs rastros dos requisitos podem ser de dois
tipos:• Pré-rastreabilidade: os rastros
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 321/338
(artefatos: plano de negocio, atas de reuniãocom o usuário) que fundamentaram a
criação do requisito.• Pós-rastreabilidade: os rastros
(artefatos: código, documentos) que seformaram a partir do requisito criado.
Rastreabilidade
• Rastreamento de Origem
– Associação entre requisitos e stakeholders que propuseram tais requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 322/338
q p p q
• Rastreamento de Requisitos– Associação entre requisitos dependentes
• Rastreamento de Projeto– Associação dos requisitos com o projeto
• Usar hipertexto ou referência cruzada– Ou matriz de rastreamento
1. Rastrear requisitos dousuário nos do sistema2. Rastrear requisitos noprojeto
Req A
1
RequisitosProduto
(Caracter.)
Rastreabilidade Vertical
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 323/338
projeto3. Rastrear requisitos nosprocedimentos de teste4. Rastrear requisitos dousuário no plano
Projeto
Modelos Suítes Teste
Teste
2 3
1
Requisitos
Detalhados(Casos de Uso)
Req B
Plano
Doc. Usuário
4
Req A antes“if return value > $5” “if return value > $2”
Req A depois
Rastreabilidade: Análise deImpacto
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 324/338
Links dos requisitos devem ser marcados como
“suspeitos” Links suspeitos devem ser resolvidos
if return value $5
Req B
Req C
$
Req C
Req B
Rastreabilidade HorizontalRequisitos
X
Requisitos Req1 Req2 Req3 Req4 Req5
Req1
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 325/338
Req2
Req3
Req4
Req5
Organização dos requisitos
• Estruturar para que possam ser
abordados nos ciclos dedesenvolvimento
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 326/338
desenvolvimento
• Acomodados em processos denegócio conhecidos como casos deuso
• Priorizar os mais críticos deixandoara o final os mais elementares.
Planejamento dodesenvolvimento• Acomodar os diferentes casos de
uso, cadastros e consultas nos ciclos
P d ã d i l
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 327/338
• Prever a duração dos ciclos
• Determinar tamanho da equipe
• Produto final cronogramafinanceiro e de atividades para o
desenvolvimento do projeto
Gerenciar requisitos não é fácilporque...• Os requisitos:
– nem sempre são óbvios– podem surgir de várias fontes
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 328/338
– pode nem sempre ser facilmente expressadoem palavras
– se relacionam uns com os outros e com outrosprodutos no processo de engenharia desoftware
– tem propriedades únicas– mudam
• Um número grande de requisitos não égerenciável se não é controlado.
Chaves para gerenciarrequisitos efetivamente• Manter uma declaração clara dos requisitos por
meio de:– requisitos de alta qualidade
t ib t li á i d ti d i it
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 329/338
– atributos aplicáveis para cada tipo de requisito– rastreabilidade com outros requisitos e outros
artefatos de projeto
A meta é entregar produtos de qualidade no tempo e orçamento que atendam àsreais necessidades do cliente.
Como os projetos podem serbem sucedidos• Análise do problema
– Entender o problema– Obter a aceitação do cliente• Levantamento de requisitos
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 330/338
• Levantamento de requisitos– Identificar quem usará o sistema (atores)– Levantar como o sistema será usado (casos de
uso)• Gerenciamento de requisitos
– Especificar os requisitos completamente– Gerenciar expectativas, mudanças e erros
– Controlar a mudança de escopo– Envolver os membros da equipe
Envolver toda a equipe com osrequisitos• Desenvolvedores, testadores, documentadores
– Ajudam a desenvolver práticas de gerenciamentode requisitos
– Monitoram a aderência às práticas
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 331/338
Monitoram a aderência às práticas– Verificam o levantamento do processo– Documentam requisitos– Participam das revisões de requisitos– Participam do comitê de controle de mudanças– Revisam as entradas por meio da rastreabilidade– Verificam a qualidade, testabilidade e
completude
Disciplina de Configuração eMudançasPropósito: controlar mudanças e manter a integridade entre osartefatos do projeto
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 332/338
Gerência de Configuração
• As ferramentas de gerência deconfiguração suportam:
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 333/338
– Realizar baseline de versõesconcorrentes
– Identificação da configuração egerência
– Monitorar e apresentar as mudanças e
status de configuração– Seleção de Versão– Métricas dos itens sob controle
Gerência de Qualidade deRequisitos (IEEE830)• Correção: um documento de requisitos é
considerado correto se todos os requisitos representamalgo que deve estar presente no sistema que está
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 334/338
algo que deve estar presente no sistema que estásendo desenvolvido, ou seja, os requisitos reais dousuário devem coincidir com os requisitos identificados.
Esta não é uma tarefa trivial e parte de seu sucessoestá associada a uma boa atividade de validação dosrequisitos.
• ·
Gerência de Qualidade deRequisitos (IEEE830)• Não ambigüidade: um conjunto de requisitos é
não ambíguo quando somente pode ser interpretadopor todos os envolvidos em um projeto de uma única
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 335/338
por todos os envolvidos em um projeto de uma única
maneira.
• ·Completude: um conjunto de requisitos é ditocompleto quando descreve todas as demandas deinteresse dos usuários. Estas demandas incluemrequisitos funcionais, de desempenho, restrições,
atributos e interfaces externas.• ·
Gerência de Qualidade deRequisitos (IEEE830)• Consistência: um conjunto de requisitos é dito
consistente se nenhum subconjunto destes requisitosentra em conflito com os demais requisitos do sistema
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 336/338
entra em conflito com os demais requisitos do sistema.• · Verificabilidade: um requisito é verificável se
existe uma forma efetiva, em termos de tempo e custo,para que pessoas ou ferramentas indiquem se umsistema cumpre o requisito (IEEE). Em quase todas assituações, é difícil provar de forma conclusiva que umrequisito é cumprido por um software
• ·
Gerência de Qualidade deRequisitos (IEEE830)• Modificabilidade: um conjunto de requisitos é
modificável quando seu estilo e estrutura é tal que asalterações podem ser realizadas de forma simples e
8/8/2019 Engenharia de Requisitos V2
http://slidepdf.com/reader/full/engenharia-de-requisitos-v2 337/338
alterações podem ser realizadas de forma simples econsistente com os demais requisitos.
A gerência, neste cenário, é responsável por manteruma infra-estrutura necessária para atividades deverificação que tornem possível investigarmos aqualidade dos requisitos que estamos definindo
Bibliografia
• Pressman, R. Engenharia deSoftaware