Ciclo de vida processo

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. Engenharia
de Sistemas
Análise
Projeto
Codificação
Teste
Manutenção
Cascata

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
Descrição do
Esboço
Versão
Inicial
Descrição do
Esboço
Especificação
Versões
Intermediárias
Versão
Final
Desenvolvimento
Validação

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 Definição de
Requisitos e
Refinamento
Projeto
Rápido
Constru-
ção do
Protótipo
Avaliação do
Usuário
Refinamento
do protótipo
Produto
Final
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
Especificação de
Requisitos
Especificação
Formal
Transformação
Formal
Testes

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
Requisitos
Design
Codificação
Testes
Implantação
Requisitos
Design
Codificação
Testes
Implantação
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:
1. Descobrir 2. Analisar
3. Documentar 4. 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.  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
Elicitação dos Requisitos de Negócio

33. Especificação e Modelagem de Requisitos
 Elicitar Requisitos de Produto
 Especificar casos de uso e validá-los
 Especificar requisitos não funcionais
 Analisar e validar os requisitos
Requisitos
p/ Inspeção
Plano e
Casos de Teste
Casos de Uso e
Esp. Suplementar
Regras de
Negócio
Glossário
Documento de Visão
Analista de
Requisitos

34. Verificação e Validação dos Requisitos
 Verificar conflitos de requisitos
 Verificar consistência de requisitos
 Verificar completude de requisitos
 Verificar existência de requisitos ambíguos
Analista de
Requisitos
Requisitos
p/ Inspeção
Plano e
Casos de Teste
Casos de Uso e
Esp. Suplementar
 Garantir a rastreabilidade dos requisitos
 Validar requisitos com o cliente
Inspetor
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
Documento de Visão
Atualizado
Solic. Mudança
Analista de
Requisitos
Analista de
Negócios
Especificação de
Requisitos Atualizada

36. Elicitação de Requisitos

37.  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
Elicitação dos Requisitos de Negócio

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?