1. Método orientado a objetivos
1.1. Conceito de Objetivos
1.1.1. Deriva-se em Requisito.
1.1.2. Hierarquia por refinamento.
1.1.2.1. Padrão disjunção (OU):
1.1.2.1.1. Alternativas para satisfação do objetivo.
1.1.2.2. Padrão conjunção (E):
1.1.2.2.1. Detalha a descrição do objetivo.
1.2. Finalidade
1.2.1. Obter especificações UML usando objetivos.
1.2.1.1. Benefícios
1.2.1.1.1. Abstração.
1.2.1.1.2. Direção.
1.2.1.1.3. Rastreabilidade.
1.2.1.1.4. Análise.
1.3. Lista de atividades
1.3.1. Elicitar um contexto para o sistema.
1.3.2. Definir objetivos do sistema.
1.3.3. Derivar requisitos.
1.3.4. Derivar casos de uso.
1.3.5. Derivar modelos UML.
2. Fronteiras dos comportamentos
2.1. .
2.2. Comportamentos ambientais: representados pelas propriedades do domínio.
2.3. Comportamentos implementáveis: são executados pelo sistema.
2.4. Comportamentos requeridos: estão na intersecção entre comportamentos ambientais e comportamentos implementáveis
3. Derivando Casos de Uso
3.1. Casos de Uso
3.1.1. Baseados em objetivos
3.1.1.1. Abstratos
3.1.1.2. Concretos
3.1.2. Tipos
3.1.2.1. De negócios
3.1.2.2. De tarefa
3.1.2.3. De baixo nível
3.1.3. Modelagem
3.1.3.1. Reduz complexidade dos métodos O.O.
3.1.3.2. Deve ser conjugado com técnicas tradicionais de captura dos requisitos
3.1.3.2.1. Fornece um processo de gerenciamento aceitável para todas as partes interessadas no projeto.
3.1.3.3. Estratégia
3.1.3.3.1. Particionar o sistema em pequenas unidades baseadas na visão dos usuários.
4. Requisitos
4.1. Conceitos e particularidades
4.1.1. Sentido geral: informações a descobrir antes de construir o software.
4.1.2. Sentido específico: algo que o produto fará ou qualidade desse produto.
4.1.2.1. Tipo funcional: capacidade que o produto tem para realizar algo.
4.1.2.2. Tipo não-funcional : qualidades ou propriedades que o produto detém.
4.1.3. Deve satisfazer as seguintes condições.
4.1.3.1. Condicionar (restringir) comportamento de software.
4.1.3.2. Ser descrito em valores monitorados pelo software.
4.1.3.3. Restringir apenas valores controlados pelo software.
4.1.3.4. Não enquadrar valores monitorados no futuro.
4.1.4. Pode ser derivado em Especificação.
4.1.4.1. Relativo apenas às propriedades do sistema.
4.1.5. Descreve simultaneamente o ambiente e o sistema.
5. Modelagem com objetivos
5.1. Relevância.
5.1.1. Usar objetivos para fornecer um alvo para a especificação mais detalhada de software.
5.2. Usar objetivos para:
5.2.1. - conciliar desejos do usuário à funcionalidade (operacional).
5.2.2. - refinar requisitos não-funcionais (propriedades).
5.2.3. - acompanhar o andamento de projetos.
5.2.4. - obter novos requisitos quando os objetivos não forem atingidos.
5.2.5. - associação às especificações de projeto
5.3. Com padrões:
5.3.1. - de Obtenção: que algumas propriedades nem sempre prevalecem.
5.3.2. - de Término: que algumas propriedades eventualmente não prevaleçam.
5.3.3. - de Manutenção: que alguma propriedade sempre prevaleça.
5.3.4. - de Não-Ocorrência: que algumas propriedades nunca ocorram.
5.4. Propriedade de domínio.
5.5. Propriedade desejada do ambiente.
6. Ferramentas disponíveis
6.1. Aplicação:
6.1.1. Uso de instrumentos de captura e análise.
6.2. Modalidades:
6.2.1. Entrevistas.
6.2.2. Questionários.
6.2.3. Sessões de brainstorming.
6.2.4. Prototipação.
6.2.5. Instrumentos de análise com tabelas e listas de verificação.
6.2.6. Mapas mentais.
7. Contextualização
7.1. Problema: a especificação de requisitos realizada nos ambientes de desenvolvimento é feita de maneira informal e artesanalmente.
7.2. Hipótese: situação pode estar relacionada à má gestão ou à complexidade dos problemas.
7.2.1. Os problemas a serem enfrentados pela engenharia de software são imensamente complexos.
7.2.2. Compreender a natureza de cada problema é tarefa difícil, principalmente em sistemas novos.
7.3. Solução:
7.3.1. Desenvolver habilidades-chave:
7.3.1.1. Analisar o problema.
7.3.1.2. Entender as necessidades dos envolvidos.
7.3.1.3. Definir o sistema.
7.3.1.4. Gerenciar o escopo do sistema.
7.3.1.5. Refinar a definição do sistema