1. Fundamentos
1.1. Principais problemas
1.1.1. Suposição dos stakeholders de que os requisitos são claros
1.1.1.1. Alterações nos requisitos
1.1.2. Problemas de comunicação devido a conhecimento e experiências dos envolvidos
1.1.3. Pressão no prazo de entrega
1.2. Principal papel na ER
1.2.1. Engenheiro de Requisitos
1.2.1.1. Capacidades/Hablidades
1.2.1.1.1. Boa comunicação
1.2.1.1.2. Raciocínio analítico
1.2.1.1.3. Empatia
1.2.1.1.4. Resolução de conflitos
1.2.1.1.5. Moderação
1.2.1.1.6. Auto-confiança
1.2.1.1.7. Persuação
1.3. Tipos de requisitos
1.3.1. Requisitos funcionais
1.3.2. Requisitos de qualidade (requisitos não funcionais)
1.3.2.1. Detalhamento da funcionalidade
1.3.2.1.1. Segurança
1.3.2.1.2. Acurácia de cálculo
1.3.2.1.3. Adequação
1.3.2.1.4. Interoperabilidade
1.3.2.2. Confiabilidade
1.3.2.2.1. Recuperabilidade
1.3.2.2.2. Tolerância a falhas
1.3.2.3. Usabilidade
1.3.2.3.1. Integibilidade
1.3.2.3.2. Atratividade
1.3.2.4. Eficiência
1.3.2.4.1. Utilização de recursos
1.3.2.4.2. Comportamento em relação ao tempo
1.3.2.5. Manutenibilidade
1.3.2.5.1. Testabilidade
1.3.2.5.2. Escalabilidade
1.3.2.6. Portabilidade
1.3.2.6.1. Adaptabilidade
1.3.2.6.2. Capacidade para ser instalado
1.3.3. Restrições
1.3.3.1. Tempo
1.3.3.2. Custo
1.3.3.3. Tecnologias
2. Sistema e Contexto do Sistema
2.1. Contexto do sistema
2.1.1. Encontra-se as fontes e justificativas de um sistema
2.1.1.1. Pessoas
2.1.1.1.1. Stakeholders
2.1.1.2. Sistemas em operação
2.1.1.2.1. Software
2.1.1.2.2. Hardware
2.1.1.2.3. Sistemas técnicos
2.1.1.3. Processos
2.1.1.3.1. Processos de negócios
2.1.1.3.2. Processos técnicos
2.1.1.3.3. Processos físicos
2.1.1.4. Eventos
2.1.1.4.1. Eventos técnicos
2.1.1.4.2. Eventos físicos
2.1.1.5. Documentos
2.1.1.5.1. Normas
2.1.1.5.2. Regulamentações
2.1.1.5.3. Documentação de sistema
2.1.2. Identifica a parte do ambiente que tem uma relação com o sistema a ser desenvolvido
2.1.3. Diagramas
2.1.3.1. Casos de uso
2.1.3.1.1. Atores
2.1.3.2. Fluxo de dados
2.1.3.2.1. Fornecedores de dados no ambiente
2.1.3.2.2. Consumidores de dados no ambiente
2.2. Limite do sistema
2.2.1. Determina quais aspectos cobertos pelo sistema planejado e quais partes do ambiente
2.2.2. Zona cinzenta
2.2.2.1. As funções e qualidades do sistema planejado são incompletas ou desconhecidas durante a ER
2.2.2.2. O limite do sistema pode se alocar dentro da zona cinzenta e/ou a zona cinzenta sofrer modificações durante a ER
2.3. Limite do contexto
2.3.1. Pode sofrer alterações com o tempo
2.3.2. Zona cinzenta
2.3.2.1. Engloba os aspectos identificados do ambiente cuja relação com o sistema planejado não está clara
3. Atividades
3.1. Elicitação
3.1.1. Bases da elicitação de requisitos
3.1.1.1. Contexto do sistema
3.1.1.2. Fontes de requisitos
3.1.1.2.1. Stakeholders
3.1.1.2.2. Documentos
3.1.1.2.3. Sistemas legados
3.1.2. Classificação de requisitos conforme Modelo Kano
3.1.2.1. Fatores
3.1.2.1.1. Fatores básicos de satisfação
3.1.2.1.2. Fatores esperados de satisfação
3.1.2.1.3. Fatores de entusiasmo
3.1.2.2. Recomendado pesquisa de campo para identificar os fatores
3.1.3. Técnicas de elicitação
3.1.3.1. Técnicas de pesquisa
3.1.3.1.1. Entrevistas
3.1.3.1.2. Questionários
3.1.3.2. Técnicas de criatividade
3.1.3.2.1. Brainstorming
3.1.3.2.2. Mudança de perspectiva
3.1.3.2.3. Analogias
3.1.3.3. Técnicas baseadas em documentos
3.1.3.3.1. Arqueologia de sistema
3.1.3.3.2. Leitura baseada em perspectiva
3.1.3.3.3. Reutilização de requisitos
3.1.3.4. Técnicas de observação
3.1.3.4.1. Pesquisa de campo
3.1.3.4.2. Apprenticing
3.1.3.5. Técnicas de apoio
3.1.3.5.1. Mapas mentais
3.1.3.5.2. Workshops
3.1.3.5.3. Cartões CRC
3.1.3.5.4. Gravação de áudio
3.1.3.5.5. Casos de uso
3.1.3.5.6. Protótipos
3.1.3.6. Aspectos importantes na escolha de uma ou mais técnica
3.1.3.6.1. Fatores de riscos
3.1.3.6.2. Influências humanas
3.1.3.6.3. Influências organizacionais
3.1.3.6.4. Influências técnicas
3.1.3.6.5. Nível esperado de detalhamento do documento de requisitos
3.2. Documentação
3.2.1. Técnicas de documentação
3.2.1.1. Linguagem natural
3.2.1.1.1. Problemas
3.2.1.1.2. Templetes de sentenças
3.2.1.2. Modelos conceituais
3.2.1.2.1. Diagramas
3.2.1.2.2. Vantagens
3.2.1.2.3. Propriedades
3.2.1.2.4. É definido por sintaxe semântica
3.2.1.2.5. Metas
3.2.1.2.6. Perspectiva
3.2.1.3. Formas combinadas
3.2.1.3.1. Obtem os melhores resultados
3.2.2. Garente um respaldo na comunicação e metas
3.2.2.1. Os requisitos são duradouros
3.2.2.2. Juridicamente relevantes
3.2.2.3. Acessíveis a todos
3.2.3. Etrutura de documentos
3.2.3.1. IEEE 830-1998
3.2.4. Base para outras atividades
3.2.4.1. Planejamento
3.2.4.2. Projeto de arquitetura
3.2.4.3. Implantação
3.2.4.4. Testes
3.2.4.5. Gerenciamento de mudanças
3.2.4.6. Utilização do sistema e manutenção do sistema
3.2.4.7. Gerenciamento de contratos
3.2.4.8. Suporte
3.2.4.9. Treinamentos
3.2.5. Critérios de qualidade
3.2.5.1. Documento
3.2.5.1.1. Consistente e sem ambiguidade
3.2.5.1.2. Claramente estruturado
3.2.5.1.3. Modificável e extensível
3.2.5.1.4. Completo
3.2.5.1.5. Rastreável
3.2.5.2. Requisitos
3.2.5.2.1. Acordado
3.2.5.2.2. Priorizado
3.2.5.2.3. Não ambíguo
3.2.5.2.4. Válido e atualizado
3.2.5.2.5. Correto
3.2.5.2.6. Consistente
3.2.5.2.7. Verificável
3.2.5.2.8. Realizável
3.2.5.2.9. Completo
3.2.5.2.10. Compreensível
3.2.6. Glossário
3.2.6.1. Deve conter
3.2.6.1.1. Termos técnicos específicos para determinado contexto
3.2.6.1.2. Abreviações e acrônimos
3.2.6.1.3. Conceitos do dia a dia com sentido específico em determinado contexto
3.2.6.1.4. Sinônimos
3.2.6.1.5. Homônimos
3.2.6.2. Regras
3.2.6.2.1. Deve ser gerenciado de forma centralizada
3.2.6.2.2. Definir as resposabilidades pela manutenção
3.2.6.2.3. Deve ser mantido ao longo do projeto
3.2.6.2.4. Deve ser acessível a todos os participantes do projeto
3.2.6.2.5. Deve ser obrigatória a utilização
3.2.6.2.6. Mencionar a origem dos termos
3.2.6.2.7. Deve ser aprovado pelos stakeholders
3.2.6.2.8. Deve ter uma estrutura consistente
3.3. Validação e negociação
3.3.1. Determina se os requisitos satisfazem os critérios de qualidade
3.3.2. Detectar e corrigir erros o mais cedo possível
3.3.3. Aspectos de qualidade de requisitos
3.3.3.1. Conteúdo
3.3.3.1.1. Completude do documento de requisitos
3.3.3.1.2. Completude de cada requisito
3.3.3.1.3. Rastreabilidade
3.3.3.1.4. Exatidão e adequação
3.3.3.1.5. Consistência
3.3.3.1.6. Nenhuma decisão do projeto prematura
3.3.3.1.7. Verificabilidade
3.3.3.1.8. Necessidade
3.3.3.2. Documentação
3.3.3.2.1. Conformidade com o formato de documentação
3.3.3.2.2. Conformidade com a estrutura de documentação
3.3.3.2.3. Integibilidade
3.3.3.2.4. Não ambiguidade
3.3.3.2.5. Conformidade com regras de documentação
3.3.3.3. Acordo
3.3.3.3.1. Acordado
3.3.3.3.2. Acordado após alteração
3.3.3.3.3. Conflitos resolvidos
3.3.4. Princípios de validação
3.3.4.1. Envolvimento dos stakeholders corretos
3.3.4.2. Separação da busca de falhas da correção de defeitos
3.3.4.3. Validação a partir e pontos de vista diversos
3.3.4.4. Validação a partir da mudança do tipo de documentação, quando adequado
3.3.4.5. Validação a partir da construção de artefatos de desenvolvimento baseado nos requisitos
3.3.4.6. Revalidação de requisitos em diferentes pontos ao longo do processo de desenvolvimento
3.3.5. Técnicas de validação
3.3.5.1. Parecer de especialista
3.3.5.2. Inspeção
3.3.5.3. Walkthrough
3.3.5.4. Técnicas adicionais
3.3.5.4.1. Leitura baseada em perspectiva
3.3.5.4.2. Validação por protótipos
3.3.5.4.3. Utilização de checklists
3.3.6. Acordo de requisitos
3.3.6.1. Identificação de conflitos
3.3.6.2. Análise de conflitos
3.3.6.3. Resolução de conflitos
3.3.6.3.1. Acordo
3.3.6.3.2. Compromisso
3.3.6.3.3. Votação
3.3.6.3.4. Análise alternativa
3.3.6.3.5. Manda quem pode
3.3.6.3.6. Obter mais informações
3.3.6.3.7. Pontos fortes e pontos fracos
3.3.6.3.8. Matriz de decisão
3.3.6.4. Documentação da resolução de conflitos
3.3.6.5. Tipos de conflitos
3.3.6.5.1. Conflito de conteúdo
3.3.6.5.2. Conflito de interesses
3.3.6.5.3. Conflito de valores
3.3.6.5.4. Conflito de relacionamento
3.3.6.5.5. Conflito de poder
3.3.6.6. Documento de resolução de conflitos
3.3.6.6.1. Motivo do conflito
3.3.6.6.2. Stakeholders envolvidos na resolução
3.3.6.6.3. Opiniões dos envolvidos
3.3.6.6.4. Meios utilizados para resolução
3.3.6.6.5. Alternativas possíveis
3.3.6.6.6. Decisões e razões apresentadas
3.4. Gerenciamento dos requisitos
3.4.1. Atributos de requisitos
3.4.1.1. Condições que define os atributos
3.4.1.1.1. Contexto da gerência
3.4.1.1.2. Diretrizes da empresa
3.4.1.1.3. Regras do domínio da aplicação
3.4.1.1.4. Restrições do processo de desenvolvimento
3.4.1.2. Atributos
3.4.1.2.1. Identificador
3.4.1.2.2. Nome
3.4.1.2.3. Descrição
3.4.1.2.4. Fonte
3.4.1.2.5. Estabilidade
3.4.1.2.6. Criticalidade
3.4.1.2.7. Prioridade
3.4.1.2.8. Responsabilidade legal
3.4.2. Visualização de requisitos
3.4.2.1. O usuário não precisa ver todos os requisitos
3.4.2.1.1. Visualização seletiva
3.4.2.1.2. Visualização consolidada
3.4.3. Priorização de requisitos
3.4.3.1. Definir as metas e as restrições da prioriação
3.4.3.2. Definir os critérios de priorização
3.4.3.3. Determinar os stakeholders relevantes
3.4.3.4. Selecionar os artefatos a serem priorizados
3.4.3.5. Exemplo de técnicas
3.4.3.5.1. Ranking
3.4.3.5.2. Top 10
3.4.3.5.3. Classificação de Kano
3.4.3.5.4. Alto, médio e baixo
3.4.3.5.5. Planning poker
3.4.4. Rastreabilidade
3.4.4.1. Vantagens
3.4.4.1.1. Simplificação da verificabilidade
3.4.4.1.2. Identificação das propriedades desnecessárias do sistema
3.4.4.1.3. Identificação dos requisitos desnecessários
3.4.4.1.4. Respaldo para análise de impacto
3.4.4.1.5. Respaldo para reuso
3.4.4.1.6. Respaldo para determinar responsabilidades
3.4.4.1.7. Respaldo para manutenção e administração
3.4.4.2. Classes de relacionamento de rastreabilidade
3.4.4.2.1. Rastreabilidade pré-especificação de requisitos
3.4.4.2.2. Rastreabilidade pós-especificação de requisitos
3.4.4.2.3. Rastreabilidade entre requisitos
3.4.4.3. Representação da rastreabilidade
3.4.4.3.1. Referências textuais
3.4.4.3.2. Links
3.4.4.3.3. Matriz de rastreabilidade
3.4.4.3.4. Grafos de rastreabilidade
3.4.5. Versionamento
3.4.5.1. Configuração
3.4.5.1.1. Caracteristicas
3.4.5.2. Baseline
3.4.5.2.1. Conjuto de requistos estáveis
3.4.6. Gerenciamento de mudanças
3.4.6.1. Comitê de controle de mudanças (CCB)
3.4.6.1.1. Integrantes
3.4.6.1.2. Atribuições
3.4.6.2. Documento de solicitação de mudança
3.4.6.2.1. ID
3.4.6.2.2. Título
3.4.6.2.3. Descrição
3.4.6.2.4. Justificativa
3.4.6.2.5. Data
3.4.6.2.6. Solicitante
3.4.6.2.7. Prioridade
3.4.6.3. Tipos de mudanças
3.4.6.3.1. Corretivas
3.4.6.3.2. Adaptativa
3.4.6.3.3. Excepcionais
3.4.6.4. Passos
3.4.6.4.1. Analisar o impacto e avaliar a mudança
3.4.6.4.2. Priorizar a solicitação de mudança
3.4.6.4.3. Alocar a mudança em um projeto de modificação
3.4.6.4.4. Comunica a decisão
4. Ferramentas
4.1. Ferramentas de apoio
4.1.1. Ferramentas de teste
4.1.2. Controle de versão
4.1.3. Wiki
4.1.4. Ferramentas de modelagem
4.1.5. Pacote office
4.1.6. Quadros físicos
4.2. Funcionalidades
4.2.1. Gerenciar diversos tipos de informações
4.2.2. Estabelecer e manter relacionamentos lógicos entre as informações
4.2.3. Identificar os artefatos de forma única
4.2.4. Controle de acesso
4.2.5. Diferentes formas de visualização
4.2.6. Organizar informações
4.2.7. Relatórios
4.2.8. Gerar documentos
4.3. Implantando ferramentas
4.3.1. Planejar recursos
4.3.2. Projeto piloto
4.3.3. Realizar a avaliação conforme critérios específicos
4.3.4. Custo total
4.3.5. Treinar usuários
4.4. Avaliar ferramentas
4.4.1. Perspectivas do projeto
4.4.1.1. Apoio a gestão de projetos
4.4.2. Perspecita de usuário
4.4.2.1. Usabilidade
4.4.2.2. Aprendibilidade
4.4.3. Perspectiva do produto
4.4.3.1. Funcionalidades
4.4.3.2. Confiabilidade
4.4.4. Perspectiva de processo
4.4.4.1. Metodológia usada
4.4.5. Perspectiva do fornecedor
4.4.5.1. Suporte
4.4.5.2. Continuidade do projeto
4.4.5.3. Garantias
4.4.6. Perspectivas técnicas
4.4.6.1. Interopeabilidade
4.4.6.2. Escalabilidade
4.4.6.3. Tecnologias utilizadas
4.4.7. Perspectiva econômica
4.4.7.1. Custo
4.4.7.2. Benefícos