O processo de Engenharia de Requisitos - PowerPoint PPT Presentation

About This Presentation
Title:

O processo de Engenharia de Requisitos

Description:

O processo de Engenharia de Requisitos * O objetivo de ter-se pap is definidos manter uma estrututura independente da mudan a de estrutura na Petrobras. – PowerPoint PPT presentation

Number of Views:93
Avg rating:3.0/5.0
Slides: 50
Provided by: Tere1202
Category:

less

Transcript and Presenter's Notes

Title: O processo de Engenharia de Requisitos


1
O processo de Engenharia de Requisitos
2
2. Obtenção e Análise dos Requisitos
  • 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 o sistema produz e consome
  • qual o comportamento do sistema
  • quais as características de interface com outros
    subsistemas
  • quais são as restrições do projeto

3
A Gerência do Processo de Desenvolvimento
4
Ciclo de Vida
  • Qual o propósito de estabelecer um Ciclo de Vida
    para o Software?
  • Definir que atividades devem ser executadas em um
    projeto de desenvolvimento de sistemas
  • Introduzir consistência entre vários projetos de
    desenvolvimento de sistemas de uma mesma
    organização
  • Prover pontos de controle para prever, gerenciar
    e controlar o desenvolvimento de sistemas

5
Ciclo de Vida
  • Cascata
  • Evolucionário
  • Formal
  • Orientado a Reuso
  • Espiral
  • Incremental

6
Cascata
  • Ciclo de Vida Clássico
  • Prevê um processo de desenvolvimento com etapas
    seqüenciais
  • Base engenharia convencional
  • O resultado de cada fase envolve a elaboração de
    um ou mais documentos que são aprovados

7
Cascata

Engenharia de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
8
Cascata
  • Problemas
  • Para grandes projetos o tempo que decorre desde a
    especificação até sua implantação é grande
  • O Ambiente Externo evolui e é diferente daquele
    que deu origem a sua especificação
  • Na prática os estágios se sobrepõem
  • O processo de software envolve interações

9
Evolucionário
  • Base
  • Desenvolver uma implementação inicial
  • Expor o resultado ao comentário do usuário
  • Aprimoramento por meio de muitas versões
  • Até que o sistema tenha sido totalmente
    desenvolvido
  • Dois tipos
  • Exploratório
  • Protótipos descartáveis

10
Evolucionário
  • Exploratório
  • Trabalhar com o cliente
  • O desenvolvimento inicia com as partes do sistema
    que são compreendidas
  • O sistema evolui com as novas características
    propostas pelo cliente
  • Protótipos descartáveis
  • O protótipo experimenta os requisitos não
    compreendidos
  • Neste caso o objetivo é a Especificação de
    Requisitos
  • Falaremos de protótipos mais adiante

11
Evolucionário
Versão Inicial
Especificação
Versões Intermediárias
Desenvolvimento
Descrição do Esboço
Descrição do Esboço
Validação
Versão Final
12
Evolucionário
  • Produz sistemas que atendem as necessidades
    imediatas do cliente
  • Problemas
  • O processo não é visível
  • Não se produzem documentos que reflitam as
    versões do sistema
  • Freqüentemente são mal estruturados
  • Software sem estrutura
  • Modificações cada vez mais custosas
  • Ferramentas e técnicas especiais
  • Possibilitam rápido desenvolvimento
  • Poucas pessoas podem ter a habilitação necessária
    para usá-las

13
Evolucionário
Início
Fim
14
Formal
  • Base a transformação matemática formal de uma
    especificação de sistema em um programa
    executável
  • A especificação de requisitos é redefinida com
    uma linguagem formal

15
Formal
  • Transformação formal
  • Várias etapas
  • Representação mais detalhada, matematicamente
    correta
  • Adequada a sistemas críticos
  • Permite verificação automática de consistência
  • Model checking
  • utiliza máquinas de estado para verificar onde
    uma determinada propriedade é satisfeita sob
    todas as condições
  • Prova de teoremas
  • axiomas do comportamento do sistema são
    empregados para derivar uma prova de que o
    sistema vai se comportar de uma determinada forma

16
Orientado a Reuso
  • Ampla base de componentes reusáveis
  • Infra-estrutura de integração
  • Etapas
  • De posse da Especificação de Requisitos,
    buscam-se componentes para implementá-la
  • Negociação requisitos são modificados para que
    se possa usar os componentes
  • Redução do esforço de desenvolvimento

17
Iteração de processo
  • Existe a necessidade de utilizar diferentes
    abordagens para diferentes partes do sistema
  • Partes do processo são repetidas enquanto os
    requisitos evoluem
  • Modelos Híbridos
  • Apóiam a iteração do processo
  • Desenvolvimento Espiral
  • Desenvolvimento Incremental

18
Modelo Espiral
  • O processo de desenvolvimento se move sobre uma
    espiral evolucionária
  • Melhores características do
  • Ciclo de vida clássico
  • Evolucionário Prototipação
  • Acrescenta Análise de Riscos
  • As fases são executadas de forma iterativa
  • As fases de análise e projeto não são monolíticas
    e distintas

19
Modelo Espiral
20
Modelo Espiral
  • Planejamento
  • objetivos, alternativas e restrições
  • Análise de Riscos
  • Análise de alternativas e identificação/resolução
    de riscos
  • Prototipação pode ser usada
  • Simulações e outros modelos podem ser usados para
    definir melhor o problema
  • Desenvolvimento e Validação
  • Desenvolvimento do produto no nível seguinte
  • Avaliação feita pelo Cliente
  • Volta ao Planejamento

21
Enfoque Incremental
  • Uma variação do modelo cascata onde a partir da
    fase de especificação de requisitos são feitos
    incrementos sucessivos.
  • Estratégia para minimizar riscos, obtendo-se
    resultados de médio e curto prazo sem se
    descuidar do objetivo final

22
Enfoque Incremental
Uma interação
tempo
23
Desenvolvimento Incremental
  • O Processo de Desenvolvimento RUP está em
    conformidade com o Desenvolvimento Incremental.

24
Desenvolvimento Incremental
  • Em vez de entregar o sistema como um todo, o
    desenvolvimento e a entrega são divididos em
    partes, com cada incremento entregando parte da
    funcionalidade requerida
  • Requisitos dos usuários são priorizados e os
    requisitos de mais alta prioridade são incluídos
    nas iterações iniciais
  • Uma vez que o desenvolvimento de um incremento é
    iniciado, os requisitos são "congelados, embora
    possam continuar a evoluir para incrementos
    posteriores

25
Desenvolvimento Iterativo e Incremental (RUP)
26
Engenharia de Requisitos
27
Engenharia de Requisitos
  • Compreender a natureza do software a ser
    desenvolvido é realmente muito complexo
  • Conseqüentemente é difícil estabelecer o que o
    sistema deve fazer
  • Estabelecer o que o sistema deve fazer
    descrevendo suas funções e restrições é conseguir
    determinar todos os seus requisitos
  • O Processo de

Descobrir Analisar
Documentar Verificar
É chamado de Engenharia de Requisitos
28
Engenharia de Requisitos
29
Engenharia de Requisitos
  • O processo de estabelecer as funções que um
    cliente requer de um sistema e as restrições sob
    as quais ele deve funcionar e ser desenvolvido
  • Os requisitos são descrições das funções e
    restrições que são geradas durante o processo de
    engenharia de requisitos

30
Atividades de Engenharia de Requisitos
Recursos Humanos
31
Organização e Responsabilidade - Papéis
Analista de Negócios Negocia junto com os clientes e os demais envolvidos a lista dos requisitos iniciais e suas ampliações, priorizando-os e quando necessário agrupando-os em pacotes a serem desenvolvidos em iterações. É responsável por explicitar as regras de negócio e o glossário associado ao negócio.
Analista de Requisitos Elicita os requisitos de produto e registrá-os de forma adequada. Garante a rastreabilidade dos requisitos de negócio e requisitos de produto ao longo do projeto.
Cliente Aprova a versão final do escopo da aplicação, descrito na Especificação de Requisitos de software
Inspetor Inspeciona a Especificação de Requisitos de Software com relação ao formato.
Testador Aplica o Plano de Testes e assegura que os requisitos implementados estão de acordo com o requisitado pelo cliente.
32
Elicitação dos Requisitos de Negócio
  • Explicitar o domínio do problema
  • Identificar possibilidade de reuso de solução
  • Identificar pessoas e áreas impactadas
  • Elicitar e classificar os requisitos de negócio
  • Envolver a área de serviços e definir
  • alternativas de solução
  • Analisar e validar os requisitos

Necessidades
Analista de Negócios
Regras de Negócio
Glossário
Documento de Visão
33
Especificação e Modelagem de Requisitos
Regras de Negócio
Glossário
Documento de Visão
  • Elicitar Requisitos de Produto
  • Especificar casos de uso e validá-los
  • Especificar requisitos não funcionais
  • Analisar e validar os requisitos

Analista de Requisitos
Requisitos p/ Inspeção
Plano e Casos de Teste
Casos de Uso e Esp. Suplementar
34
Verificação e Validação dos Requisitos
Requisitos p/ Inspeção
Plano e Casos de Teste
Casos de Uso e Esp. Suplementar
  • Verificar conflitos de requisitos
  • Verificar consistência de requisitos
  • Verificar completude de requisitos
  • Verificar existência de requisitos ambíguos

Inspetor
  • Garantir a rastreabilidade dos requisitos
  • Validar requisitos com o cliente

Analista de Requisitos
Especificação de Requisitos Atualizada
Resultado dos Casos de Teste
35
Rastreabilidade e Gestão de Mudanças
  • Avaliar o impacto nos requisitos
  • Validar com o cliente
  • Notificar os envolvidos
  • Atualizar as especificações de requisitos
  • Garantir a rastreabilidade nos requisitos

Necessidade
Analista de Negócios
Solic. Mudança
Analista de Requisitos
Documento de Visão Atualizado
Especificação de Requisitos Atualizada
36
Elicitação de Requisitos
37
Elicitação dos Requisitos de Negócio
  • Explicitar o domínio do problema
  • Identificar possibilidade de reuso de solução
  • Identificar pessoas e áreas impactadas
  • Elicitar e classificar os requisitos de negócio
  • Envolver a área de serviços e definir
  • alternativas de solução
  • Analisar e validar os requisitos

Necessidades
Analista de Negócios
Regras de Negócio
Glossário
Documento de Visão
38
Elicitação de Requisitos
  • Atividades que envolvem a descoberta de
    requisitos de um sistema
  • identificação das fontes de informação
  • técnicas de elicitação (coleta de fatos)
  • comunicação (estabelecer uma linguagem comum)
  • Envolve pessoal objetivando descobrir
  • o domínio de aplicação
  • serviços que devem ser fornecidos
  • restrições

39
Elicitação de Requisitos
  • Pode envolver diferentes tipos de pessoas em uma
    organização (stakeholders)
  • usuários
  • gerentes
  • desenvolvedores
  • especialistas de domínio
  • sindicatos,...
  • A equipe de desenvolvimento e clientes trabalham
    em conjunto visando identificar
  • detalhes do domínio da aplicação
  • serviços que o sistema deve oferecer
  • desempenho
  • restrições de hardware, ...

40
Elicitação de Requisitos
  • Problemas
  • Em geral, stakeholders não sabem o que querem de
    fato
  • dificuldade de expressão
  • pedidos não realistas
  • Stakeholders expressam requisitos em sua própria
    terminologia
  • conhecimento implícito
  • Stakeholders distintos podem ter requisitos
    conflitantes
  • Fatores políticos podem influenciar os requisitos
    do sistema
  • Ambientes econômicos e de negócios são dinâmicos
  • requisitos mudam durante o processo de análise
  • novos requisitos podem surgir (novos stakeholders)

41
Elicitação de Requisitos
  • Atividades do Processo
  • Compreensão do domínio
  • Coleta de requisitos
  • Classificação
  • Resolução de conflitos
  • Definição de Prioridades
  • Verificação de requisitos

42
Compreensão do Domínio
  • Os analistas devem desenvolver sua compreensão do
    domínio da aplicação
  • se estiver desenvolvendo um sistema de
    supermercado deverá descobrir como este funciona
  • utilizar técnicas para descobrir este
    funcionamento
  • aprender a linguagem do usuário
  • elaborar um Glossário

43
Coleta de Requisitos
  • Interagir com stakeholders para descobrir os
    requisitos
  • A coleta de requisitos é feita através de
    técnicas
  • Os requisitos são simplesmente documentados à
    medida que são coletados
  • resulta em documento preliminar (draft)

44
Classificação dos Requisitos
  • Consiste basicamente em agrupar os diversos
    requisitos coletados em categorias bem-definidas
  • Classificação
  • Funcional
  • Ex. Deve ser possível consultar o preço de uma
    mercadoria
  • Não Funcional
  • Ex. A consulta deve retornar uma resposta em no
    máximo 5s
  • Inversos
  • Ex. O sistema não fará controle de estoque.

45
Resolução de Conflitos
  • É normal que ocorram requisitos conflitantes
  • Por exemplo
  • R-23 O sistema deve ...
  • R-45 O sistema não deve ...
  • Cliente é o responsável por resolver conflitos e
    ambigüidades

46
Atribuição de Prioridade
  • Alguns requisitos são mais urgentes que outros
  • É essencial determinar a prioridade dos
    requisitos junto ao cliente
  • Requisitos de maior prioridade são considerados
    em primeiro lugar

47
Prioridade
  • Requisitos podem ser agrupados em classes, por
    exemplo
  • Essenciais
  • Importantes
  • Desejáveis
  • Em princípio, o sistema deve abranger todos os
    requisitos de essenciais para desejáveis

48
Exemplo de Prioridade
  • A consulta ao extrato bancário deve retornar
    dados do movimento até o dia anterior
  • Prioridade Essencial
  • A consulta ao extrato bancário deve visualizar
    dados segundo padrão X
  • Prioridade Importante
  • A consulta ao extrato bancário deve usar cores
    vermelhas para saldos negativos
  • Prioridade Desejável

49
Verificação de Requisitos
  • Os requisitos são verificados
  • Completos?
  • Consistentes?
  • Em concordância com o que os stakeholders desejam?
Write a Comment
User Comments (0)
About PowerShow.com