Title: O processo de Engenharia de Requisitos
1O 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
3A Gerência do Processo de Desenvolvimento
4Ciclo 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
5Ciclo de Vida
- Cascata
- Evolucionário
- Formal
- Orientado a Reuso
- Espiral
- Incremental
6Cascata
- 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
7Cascata
Engenharia de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
8Cascata
- 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
9Evolucioná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
10Evolucioná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
11Evolucioná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
12Evolucioná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
13Evolucionário
Início
Fim
14Formal
- 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
15Formal
- 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
16Orientado 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
17Iteraçã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
18Modelo 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
19Modelo Espiral
20Modelo 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
21Enfoque 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
22Enfoque Incremental
Uma interação
tempo
23Desenvolvimento Incremental
- O Processo de Desenvolvimento RUP está em
conformidade com o Desenvolvimento Incremental.
24Desenvolvimento 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
25Desenvolvimento Iterativo e Incremental (RUP)
26 Engenharia de Requisitos
27Engenharia 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
28Engenharia de Requisitos
29Engenharia 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
31Organizaçã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.
32Elicitaçã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
33Especificaçã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
34Verificaçã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
35Rastreabilidade 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
37Elicitaçã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
38Elicitaçã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
39Elicitaçã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, ...
40Elicitaçã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)
41Elicitaçã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
42Compreensã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
43Coleta 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)
44Classificaçã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.
45Resoluçã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
46Atribuiçã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
47Prioridade
- 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
48Exemplo 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
49Verificação de Requisitos
- Os requisitos são verificados
- Completos?
- Consistentes?
- Em concordância com o que os stakeholders desejam?