Gerenciamento do Ciclo de Vida dos Requisitos BABok V3

Prévia do material em texto

Capítulo 5 – Gerenciamento do Ciclo de Vida dos Requisitos – Guia BABOK volume 3. 
Gerenciamento do Ciclo de Vida dos Requisitos
A área de conhecimento do gerenciamento do ciclo de vida dos requisitos descreve as tarefas que os analistas de negócios executam para gerenciar e manter os requisitos e projetar informações desde o início até a saída. 
Essas tarefas descreve estabelecer relações significativas entre requisitos e projetos relacionados, avaliar mudanças nos requisitos e projetos quando mudanças são propostas, e analisar e obter consenso sobre mudanças.
A finalidade do gerenciamento do ciclo de vida dos requisitos é garantir que os negócios, as partes interessadas e os requisitos e projetos da solução estejam alinhados entre si e que a solução seja implementada. Envolve um nível de controle sobre requisitos e sobre como os requisitos serão implementados na atual solução a ser construída e entregue. Também ajuda a garantir que os negócios e as informações de análise estejam disponíveis para uso futuro.
O ciclo de vida dos requisitos:
• começa com a representação de uma necessidade de negócios como um requisito,
• continua através do desenvolvimento de uma solução, e
• termina quando uma solução e os requisitos que a representam são retirados.
O gerenciamento de requisitos não termina quando uma solução é implementada. Ao longo da vida de uma solução, os requisitos continuam a fornecer valor quando eles são gerenciados adequadamente. Dentro da área de conhecimento do gerenciamento do ciclo de vida dos requisitos, o conceito de um ciclo de vida é separado de uma metodologia ou processo usado para controlar o trabalho da análise dos negócios. O ciclo de vida refere-se à existência de várias fases ou estados que os requisitos passam como parte de qualquer alteração. Requisitos podem estar em vários estados ao mesmo tempo.
Gerenciamento do Ciclo de Vida dos Requisitos 
	Apresentar
	Gerir*Rastrear
* Manter
* Priorizar
Aprovação/ Consenso
Avaliar
	Sim	Sim
	
	Não 	 Não
 Requisito 
 Potencial
A área de conhecimento do gerenciamento do ciclo de vida dos requisitos inclui as seguintes tarefas:
Rastreamento de requisitos: análise e mantém as relações entre requisitos, projetos, componentes de solução e outros produtos de trabalho para análise de impacto, cobertura e alocação.
Preservação de requisitos: garante que os requisitos e projetos sejam precisos e atuais ao longo do ciclo de vida e facilita a reutilização onde for apropriada.
Priorização de requisitos: avalia o valor, a urgência e os riscos associados com requisitos e projetos específicos para assegurar que a análise e / ou o trabalho de entrega é feito nos mais importantes a qualquer momento.
Avaliação de mudanças dos requisitos: avalia novas e novas exigências das partes interessadas para determinar se eles precisam ser agidos sobre no âmbito de uma mudança.
Aprovação de requisitos: trabalha com as partes interessadas envolvidas no processo de governança para alcançar aprovação e acordo sobre requisitos e projetos.
O Modelo de Conceito Básico no Gerenciamento do Ciclo de Vida de Requisitos
O modelo de conceito central de análise de negócios (Business Concept Core Model ™ (BACCM™)) descreve o relações entre os seis conceitos principais.
A tabela a seguir descreve o uso e a aplicação de cada um dos principais conceitos dentro do contexto de Gerenciamento do Ciclo de Vida dos Requisitos.
Modelo de Conceito Básico no Gerenciamento do Ciclo de Vida dos Requisitos
	Conceito central
	Durante o gerenciamento do ciclo de vida dos requisitos, analistas de negócios fazem...
	Mudança: o ato de transformação em resposta a uma necessidade.
	Gerenciar como as alterações propostas para os requisitos e projetos são avaliadas durante uma iniciativa.
	Necessidade: um problema ou oportunidade para ser abordada.
	Traçar, priorizar e manter os requisitos para garantir que a necessidade seja atendida.
	Solução: uma forma específica de satisfazer uma ou mais necessidades em um contexto.
	Rastrear os requisitos e os projetos nos componentes da solução para garantir que a solução atenda à necessidade.
	Parte interessada: um grupo ou indivíduo com uma relação à mudança, a necessidade ou a solução.
	Trabalhar em estreita colaboração com as principais partes interessadas para manter a compreensão, o acordo e a aprovação de requisitos e projetos.
	Valor: o valor, importância ou utilidade de algo para um interveniente dentro de um contexto.
	Manter os requisitos de reutilização para estender valor além da atual iniciativa.
	Contexto: as circunstâncias que influencia, são influenciados e fornecer compreensão da mudança.
	Analisar o contexto para apoiar as atividades de rastreamento e priorização.
Diagrama de Entrada e Saídas do Gerenciamento do Ciclo de Vida dos Requisitos
Entrada
Tarefas
Saídas
5.1 – Rastreamentos de requisitos: (Trace Requirements)
Propósito
O objetivo do rastreamento dos requisitos é garantir que os requisitos e projetos em diferentes níveis sejam alinhados entre si e gerenciar os efeitos da mudança em um nível dos requisitos relacionados.
Descrição
A rastreabilidade de requisitos identifica e documenta a linhagem de cada exigência, incluindo sua rastreabilidade reversa, sua rastreabilidade e relacionamento com outros requisitos. A rastreabilidade é usada para ajudar a garantir que a solução atenda aos requisitos e ajuda no escopo, mudança, risco, tempo, custo e gerenciamento de comunicação. Ele também é usado para detectar funcionalidades ausentes ou para identificar se há funcionalidade implementada que não é suportada por nenhum requerimento.
Rastreabilidade permite:
• análise de impacto mais rápido e simples,
• descoberta mais confiável de inconsistências e lacunas nos requisitos,
• insights mais profundos sobre o escopo e a complexidade de uma mudança, e
• avaliação confiável de quais requisitos foi abordada e quais não foram.
Muitas vezes é difícil representar com precisão as necessidades e soluções sem levar em conta as relações que existem entre eles. Embora a rastreabilidade seja valiosa, o analista de negócios equilibra o número de tipos de relacionamento com o benefício obtido por representá-los.
A rastreabilidade também suporta tanto a alocação de requisitos quanto o planejamento de liberação, fornecendo uma linha direta de visão do requisito para a necessidade expressa.
As imagens a seguir mostram exemplos de representações visuais de rastreabilidade para um processo e para requisitos de software.
Rastreabilidade do Processo
Tarefa
Atividade
Subprocesso
Processo
Negócio
Cadeia de valor
Rastreabilidade dos Requisitos de Software
Necessidade do negócio
Teste
Código
Design
Requisitos da Solução
Requisitos das partes interessadas
Requisitos do negócio
Entradas
• Requisitos: podem estar relacionados a outros requisitos (incluindo metas, objetivos, requisitos de negócios, requisitos das partes interessadas, requisitos de solução e requisitos de transição), componentes de solução, recursos visuais, regras de negócios e outros produtos de trabalho.
• Projetos: podem ser rastreados para outros requisitos, componentes de solução e outros produtos de trabalho.
Diagrama de Entradas e Saídas do Rastreamento de Requisitos
	Entradas Diretrizes e ferramentasRastreamento de requisitos
Ferramentas / Repositório
Abordagem da Gestão de Informação
Informações Legais / Regulatórias
Conhecimento de domínio
Requisitos
Projetos
7.5 – Definir opções de Projeto
5.1 – Projetos
(rastreados)
5.1 – Requisitos
 (rastreados) 
	Saída
 Tarefas através desta saída
Elementos
Nível de Formalidade
 Ao rastrear requisitos, os analistasde negócios consideram o valor que cada link deve fornecer, bem como a natureza e o uso dos relacionamentos específicos que estão sendo criados. O esforço para rastrear requisitos aumenta significativamente quando o número de requisitos ou o nível de formalidade aumenta.
Relacionamentos
Existem vários tipos de relacionamentos que o analista de negócios considera ao definir a abordagem de rastreabilidade:
• Derivar: relacionamento entre dois requisitos, usado quando um requisito é derivado de outro requisito. Esse tipo de relacionamento é apropriado para ligar os requisitos em diferentes níveis de abstração. Por exemplo, um requisito de solução derivado de um requisito de negócio ou de uma parte interessada.
• Dependência: relacionamento entre dois requisitos, usado quando um requisito depende de outro requisito. Tipos de relacionamentos de dependência incluem:
• Necessidade: quando só faz sentido implementar um requisito específico se um requisito relacionado também for implementado.
• Esforço: quando um requisito é mais fácil de implementar se um requisito relacionado também é implementado.
• Satisfazer: relação entre um elemento de implementação e os requisitos que ele satisfaz. Por exemplo, o relacionamento entre um requisito funcional e um componente de solução que o está implementando.
• Validar: relacionamento entre um requisito e um caso de teste ou outro elemento que pode determinar se uma solução atende ao requisito.
Repositório de Rastreabilidade 
Rastreabilidade de requisitos é documentada e mantida de acordo com os métodos identificados pela abordagem de análise de negócios. As ferramentas de gerenciamento de requisitos podem fornecer benefícios significativos quando há a necessidade de rastrear um grande número de requisitos que podem ser considerados não gerenciáveis com abordagens manuais.
Diretrizes e Ferramentas
• Domínio do Conhecimento: conhecimento e experiência no domínio do negócio necessário para apoiar a rastreabilidade.
• Abordagem de Gerenciamento de Informações: fornece decisões de atividades de planejamento relacionadas à abordagem de rastreabilidade.
• Informação Legal / Regulamentar: descreve regras ou regulamentos legislativos que devem ser seguidos. Estes podem precisar ser considerados ao definir regras de rastreabilidade.
• Ferramentas / Repositório de Gerenciamento de Requisitos: usado para armazenar e gerenciar informações de análise de negócios. A ferramenta pode ser tão simples quanto um documento de texto ou tão complexa quanto uma ferramenta dedicada de gerenciamento de requisitos.
Técnicas
• Análise de Regras de Negócios: usada para rastrear regras de negócios para requisitos que eles suportam ou regras que suportam requisitos.
• Decomposição Funcional: usada para dividir o escopo da solução em componentes menores para alocação, bem como para rastrear conceitos de alto nível para conceitos de baixo nível.
• Modelagem de Processos: usado para mostrar visualmente o processo de estado futuro, bem como rastrear requisitos para o processo de estado futuro.
• Modelagem de escopo: usada para representar visualmente o escopo, bem como os requisitos de rastreamento para a área de escopo que o requisito suporta.
Stakeholders (Partes interessadas) 
• Clientes: são afetados por como e quando os requisitos são implementados e pode ter que ser consultado ou concordar com os relacionamentos de rastreabilidade.
• Especialista no assunto do domínio: pode ter recomendações sobre o conjunto de requisitos a serem vinculados a um componente de solução ou a um release.
• Usuário final: pode exigir relações de dependência específicas que permitem requisitos a serem implementados ao mesmo tempo ou em uma sequência específica.
• Especialista no assunto de implementação: a rastreabilidade assegura que a solução que está sendo desenvolvida atenda às necessidades do negócio e conscientiza as dependências entre os componentes da solução durante a implementação.
• Suporte operacional: a documentação de rastreabilidade fornece outra fonte de referência para suporte ao help desk.
• Gerente de projetos: a rastreabilidade suporta a mudança de projetos e o gerenciamento de escopo.
• Sponsor (Patrocinador): é necessário para aprovar os vários relacionamentos.
• Fornecedores: são afetados por como e quando os requisitos são implementados.
• Testador: precisa entender como e onde os requisitos são implementados ao criar planos de teste e casos de teste e pode rastrear casos de teste para requisitos.
Saídas
• Requisitos (rastreados): têm relações claramente definidas com outros requisitos, componentes da solução ou versões, fases ou iterações, dentro de um escopo da solução, de modo que a cobertura e os efeitos da mudança sejam claramente identificáveis.
• Projetos (rastreados): relacionamentos claramente definidos com outros requisitos, componentes da solução ou releases, fases ou iterações, dentro de um escopo da solução, de modo que a cobertura e os efeitos das alterações sejam claramente identificáveis.
Preservação de Requisitos - (Maintain Requeriments)
Objetivo:
A finalidade de manter os requisitos é manter a precisão dos requisitos e consistência ao longo e além da mudança durante todos os requisitos ciclo de vida, e para apoiar a reutilização de requisitos em outras soluções.
Descrição: Um requisito que represente uma necessidade contínua deve ser mantido para garantir que permaneça válido ao longo do tempo.
Para maximizar os benefícios da manutenção e reutilização de requisitos, os requisitos devem ser:
• consistentemente representado,
• revisado e aprovado para manutenção usando um processo padronizado que define os direitos de acesso adequados e garante a qualidade, e
• facilmente acessível e compreensível.
Entradas
• Requisitos: incluir metas, objetivos, requisitos de negócios, requisitos de partes interessadas, requisitos de solução e requisitos de transição. Estes devem ser mantidos durante todo o seu ciclo de vida.
• Projetos: podem ser mantidos durante todo o seu ciclo de vida, conforme necessário.
Diagrama de Entradas e Saídas de Preservação de RequisitosRequisitos
Projetos
5.2 - Preservação de requisitos
 Entradas
Diretrizes e ferramentas Abordagem da Gestão de Informação
5.2 – Projetos
(mantidos)
5.2 – Requisitos
 (mantidos) 
	Saída
	
	
Elementos
Preservação de requisitos
Os requisitos são mantidos para que permaneçam corretos e atualizados após uma alteração aprovada. Os analistas de negócios são responsáveis por realizar a manutenção para garantir que esse nível de precisão seja mantido. Para que os requisitos sejam mantidos adequadamente, eles devem ser claramente nomeados e definidos, e facilmente disponíveis para as partes interessadas.
Os analistas de negócios também mantêm os relacionamentos entre requisitos, conjuntos de requisitos e informações de análise de negócios associadas para garantir que o contexto e a intenção original do requisito sejam preservados.
Repositórios com taxonomias aceitas auxiliam no estabelecimento e manutenção de ligações entre os requisitos mantidos e facilitam a rastreabilidade de requisitos e projetos.
 Manter atributos
Ao extrair requisitos, os analistas de negócios obtêm atributos de requisitos. Informações como a fonte, a prioridade e a complexidade do requisito ajudam gerenciar cada requisito ao longo do ciclo de vida. Alguns atributos mudam à medida que o analista de negócios descobre mais informações e realiza análises adicionais. Um atributo pode ser alterado mesmo que o requisito não seja.
 Reutilização de requisitos
Existem situações em que os requisitos podem ser reutilizados. Requisitos que são candidatos para uso em longo prazo pela organização são identificados, claramente nomeados, definidos e armazenados de maneira a torná-los facilmente recuperáveis​​por outras partes interessadas. Dependendo do nível de abstração e necessidade pretendida, os requisitos podem ser reutilizados:
• dentro da iniciativa atual,
• dentro de iniciativas semelhantes,
• dentro de departamentos semelhantes e
• em toda a organização.
Requisitos em altos níveis de abstração podem ser escritos com referência limitada a soluções específicas. Requisitos que são representados de maneira geral, sem vínculos diretos com uma ferramenta ou estrutura organizacional específica, tendem a ser mais reutilizáveis. Esses requisitos também são menos sujeitos a revisão durante uma alteração. À medida que os requisitos são expressos com mais detalhes, eles se tornam mais fortemente associados a uma solução ou opção de solução específica. Referências específicas a aplicativos ou departamentos limitam a reutilização de requisitos e projetos em toda a organização.
Os requisitos destinados à reutilização refletem o estado atual da organização. As partes interessadas validam os requisitos propostos para reutilização antes que possam ser aceitos em uma alteração.
Diretrizes e Ferramentas
• Abordagem de Gerenciamento de Informações: indica como os requisitos serão gerenciados para reutilização.
Técnicas
• Análise de Regras de Negócios: usada para identificar regras de negócios que podem ser semelhantes em toda a empresa, a fim de facilitar a reutilização.
• Diagramas de fluxo de dados: usados para identificar o fluxo de informações que podem ser semelhantes em toda a empresa, a fim de facilitar a reutilização.
• Modelagem de dados: usada para identificar estruturas de dados que podem ser semelhantes em toda a empresa, a fim de facilitar a reutilização.
• Análise de documentos: usada para analisar a documentação existente sobre uma empresa que pode servir de base para a manutenção e reutilização de requisitos.
• Decomposição Funcional: usada para identificar os requisitos associados aos componentes e disponíveis para reutilização.
• Modelagem de Processos: usada para identificar os requisitos associados aos processos que podem estar disponíveis para reutilização.
• Casos de Uso e Cenários: usado para identificar um componente da solução que talvez seja utilizado por mais de uma solução.
• User Stories (História de usuários): usado para identificar requisitos associados à história que talvez estejam disponíveis para reutilização.
Stakeholders (Partes interessadas) 
• Especialista no assunto do domínio: as referências mantêm os requisitos regularmente para garantir que estejam refletindo com exatidão as necessidades declaradas.
• Especialista no assunto da implementação: utiliza requisitos mantidos ao desenvolver testes de regressão e conduzir análises de impacto para um aprimoramento.
• Suporte operacional: é provável que os requisitos mantidos sejam referenciados para confirmar o estado atual.
• Reguladores: é provável que os requisitos mantidos sejam referenciados para confirmar a conformidade com os padrões.
• Testadores: os requisitos mantidos são usados pelos testadores para auxiliar no plano de teste e na criação de casos de teste.
Saídas
• Requisitos (mantidos): definidos uma vez e disponíveis para uso de longo prazo pela organização. Eles podem se tornar ativos de processos organizacionais ou for usado em iniciativas futuras. Em alguns casos, um requisito que não foi aprovado ou implementado pode ser mantido para uma possível iniciativa futura.
•Projetos (mantidos): podem ser reutilizáveis uma vez definidos. Por exemplo, como um componente autônomo que pode ser disponibilizado para possível uso futuro.
Priorização de Requisitos – (Pririotize Requeriments)
Propósito
O objetivo de Priorizar Requisitos é classificar os requisitos na ordem de importância relativa.
Descrição
Priorização é o ato de classificar os requisitos para determinar sua importância relativa para as partes interessadas. Quando um requisito é priorizado, é dada maior ou menor prioridade. Prioridade pode se referir ao valor relativo de um requisito ou à sequência na qual ele será implementado. A priorização é um processo contínuo, com as prioridades mudando conforme o contexto muda. As interdependências entre os requisitos são identificadas e podem ser usadas como base para priorização. A priorização é um exercício crítico que busca garantir que o valor máximo seja alcançado.
Entradas
• Requisitos: quaisquer requisitos na forma de texto, matrizes ou diagramas prontos para priorizar.
• Projeto: quaisquer projetos na forma de texto, protótipos ou diagramas prontos para priorizar.
Diagrama de Entradas e Saídas de Priorização de Requisitos
	Entradas Diretrizes e ferramentasRestrições dos Negócios
5.3 – Priorização de requisitos
Requisitos
Projetos
6.3 – Avaliar Riscos
5.3 - Projetos
(priorizados)
5.3 – Requisitos
(priorizados)
Estratégia de Mudança
Conhecimento do domínio
Abordagem da Governança
Arquitetura dos Requisitos
	Saída
Ferramentas de Gerenciamento de Requisitos / Repositório
Escopo da Solução
 Tarefas através desta saída
Elementos
 Base para priorização
A base sobre a qual os requisitos são priorizados é acordada pelos stakeholders (partes interessadas), conforme definido na área de conhecimento Planejamento e Monitoramento de Análise de Negócios. Fatores típicos que influenciam a priorização incluem:
• Benefício: a vantagem que se acumula para as partes interessadas como resultado da implementação dos requisitos, medida de acordo com as metas e objetivos da mudança. O benefício fornecido pode se referir a uma funcionalidade específica, qualidade desejada, meta estratégica ou objetivo de negócios. Se houver vários interessados, cada grupo poderá perceber os benefícios de maneira diferente. A resolução de conflitos e a negociação podem ser empregadas para chegar a um consenso sobre o benefício geral.
• Penalidade: as consequências que resultam da não implementação de um determinado requisito. Isso inclui a priorização de requisitos para atender a exigências regulatórias ou políticas impostas à organização, que podem ter precedência sobre os interesses de outras partes interessadas. A penalidade também pode se referir à consequência negativa de não implementar um requisito que melhore a experiência de um cliente.
• Custo: o esforço e os recursos necessários para implementar o requisito. As informações sobre custo geralmente são fornecidas pela equipe de implementação ou pelo fornecedor. Os clientes podem alterar a prioridade de um requisito depois de saberem o custo. O custo é frequentemente usado em conjunto com outros critérios, como a análise de custo-benefício.
• Risco: a chance de que o requisito não possa entregar o valor potencial ou não possa ser atingido. Isso pode incluir muitos fatores, como a dificuldade de implementar um requisito ou a chance de os interessados não aceitarem um componente de solução. Se houver o risco da solução não ser tecnicamente viável, o requisito que é mais difícil de implementar e pode ser priorizado no topo da lista, a fim de minimizar os recursos gastos antes de se saber que uma solução proposta não pode ser entregue. Uma prova de conceito pode ser desenvolvida para estabelecer que opções de alto risco sejam possíveis.
• Dependências: relações entre requisitos em que um requisito não pode ser atendido a menos que o outro requisito seja atendido. Em algumas situações, pode ser possível obter eficiências implementando requisitos relacionados ao mesmo tempo. Dependências também podem ser externas à iniciativa, incluindo, entre outras, decisões de outras equipes, compromissos de financiamento e disponibilidade de recursos. Dependências são identificadas como parte dos Rastreamentos de Requisitos da tarefa (p. 79).
• Sensibilidade do Tempo: a data do 'melhor antes' do requisito, após o qual a implementação do requisito perde um valor significativo. Issoinclui cenários de time to market, nos quais o benefício derivado será exponencialmente maior se a funcionalidade for entregue antes da concorrência. Também pode se referir à funcionalidade sazonal que só tem valor em uma época específica do ano.
• Estabilidade: a probabilidade de que o requisito mude, porque requer análise adicional ou porque os interessados não chegaram a um consenso sobre isso. Se um requisito não for estável, ele poderá ter uma prioridade mais baixa, a fim de minimizar o retrabalho imprevisto e o desperdício de esforços.
• Conformidade regulatória ou de políticas: requisitos que devem ser implementados para atender às exigências regulatórias ou políticas impostas à organização, que podem ter precedência sobre os interesses de outras partes interessadas.
 Desafios da priorização
Priorização é uma avaliação de valor relativo. Cada stakeholder pode valorizar algo diferente. Quando isso ocorre, pode haver conflito entre as partes interessadas. As partes interessadas também podem ter dificuldade em caracterizar qualquer requisito como uma prioridade mais baixa, e isso pode afetar a capacidade de fazer as compensações necessárias. Além disso, as partes interessadas podem (intencionalmente ou não) indicar prioridade para influenciar o resultado até o resultado desejado. 
Diferentes tipos de requisitos podem nem todos responder aos critérios na mesma maneira e pode parecer em conflito. Pode haver necessidade das partes interessadas fazerem trade-offs (abrir mão de algum bem ou serviço distinto para obter outro bem ou serviço distinto) na priorização.
 Priorização contínua
As prioridades podem mudar à medida que o contexto evolui e à medida que mais informações se tornam disponíveis. Inicialmente, a priorização é feita em um nível mais alto de abstração. À medida que os requisitos são aperfeiçoados, a priorização é feita em um nível mais granular e incorporará bases adicionais para priorização conforme elas se tornem apropriadas. A base para a priorização pode ser diferente em vários estágios da mudança. Por exemplo, as partes interessadas podem priorizar inicialmente com base nos benefícios. A equipe de implementação pode, então, priorizar novamente os requisitos com base na sequência na qual eles devem ser implementados devido a restrições técnicas. Uma vez que a equipe de implementação tenha fornecido o custo de cada requisito, as partes interessadas podem voltar a priorizar novamente.
Diretrizes e Ferramentas
• Restrições de negócios: estatutos regulatórios, obrigações contratuais e políticas de negócios que podem definir prioridades.
• Estratégia de mudança: fornece informações sobre custos, cronogramas e realização de valor que são usados para determinar a prioridade dos requisitos.
• Conhecimento do domínio: conhecimento e especialização do domínio de negócios necessário para dar suporte à priorização.
• Abordagem de governança: descreve a abordagem para priorizar os requisitos.
• Arquitetura de Requisitos: utilizada para entender o relacionamento com outros requisitos e produtos de trabalho.
• Ferramentas / Repositório de Gerenciamento de Requisitos: incluir um atributo de requisitos para priorização pode ajudar o analista de negócios a classificar e acessar os requisitos por prioridade.
• Escopo da solução: considerado ao priorizar requisitos para garantir que o escopo seja gerenciado.
Técnicas
• Backlog Management: usado para comparar os requisitos a serem priorizados. O backlog pode ser o local onde a priorização é mantida.
• Casos de negócios: usados ​​para avaliar os requisitos em relação às metas e objetivos de negócios identificados para determinar a importância.
• Análise de decisão: usada para identificar requisitos de alto valor.
• Estimativa: usada para produzir estimativas para a base de priorização.
• Análise financeira: usada para avaliar o valor financeiro de um conjunto de requisitos e como o momento da entrega afetará esse valor.
• Entrevistas: usado para obter uma compreensão de um grupo único ou pequeno das partes interessadas com bases de priorização ou prioridades 
• Rastreamento de itens: usado para rastrear problemas levantados pelas partes interessadas durante a priorização.
• Priorização: usada para facilitar o processo de priorização.
• Análise e Gerenciamento de Risco: usado para entender os riscos para a base de priorização.
• Workshops: usados ​​para obter uma compreensão da base de prioridades ou prioridades dos stakeholders em um ambiente de grupo facilitado.
Stakeholders – (Partes Interessadas) 
• Cliente: verifica se os requisitos priorizados fornecerão valor da perspectiva do cliente ou do usuário final. O cliente também pode negociar para que a priorização seja alterada com base no valor relativo.
• Usuário final: verifica se os requisitos priorizados fornecerão valor da perspectiva do cliente ou do usuário final.
• Especialista no assunto da implementação: fornece informações relacionadas às dependências técnicas e pode negociar a mudança de prioridades com base em restrições técnicas.
• Gerente de Projeto: usa a priorização como entrada no plano do projeto e na alocação de requisitos para as liberações.
• Regulador: pode verificar se a priorização é consistente com as restrições legais e regulatórias.
• Patrocinador (Sponsor): verifica se os requisitos priorizados fornecerão valor a partir de uma perspectiva organizacional.
Saídas
• Requisitos (priorizados): os requisitos priorizados ou classificados estão disponíveis para trabalho adicional, garantindo que os requisitos mais valiosos sejam abordados primeiro.
• Projetos (priorizados): os projetos priorizados ou classificados estão disponíveis para trabalho adicional, garantindo que os designs de maior valor sejam abordados primeiro.
Avaliação de Mudanças dos Requisitos – (Assess Requirements Changes). 
Propósito
O objetivo de avaliar as mudanças nos requisitos é avaliar as implicações das mudanças propostas nos requisitos e projetos.
Descrição
A tarefa Avaliar Mudanças de Requisitos é executado à medida que novas necessidades ou possíveis soluções são identificadas. Esses podem ou não se alinhar à estratégia de mudança e / ou ao escopo da solução. A avaliação deve ser realizada para determinar se uma alteração proposta aumentará o valor da solução e, em caso afirmativo, que ação deve ser tomada. Os analistas de negócios avaliam o efeito potencial da mudança no valor da solução e se as alterações propostas introduzem conflitos com outros requisitos ou aumentam o nível de risco. Os analistas de negócios também garantem que cada mudança proposta possa ser rastreada até uma necessidade.
Ao avaliar as alterações, os analistas de negócios consideram se cada alteração proposta:
• alinha-se com a estratégia global,
• afeta o valor entregue aos negócios ou grupos de partes interessadas,
• impacta o tempo para entregar ou os recursos necessários para entregar o valor, e.
• altera quaisquer riscos, oportunidades ou restrições associadas à iniciativa geral.
Os resultados da avaliação devem apoiar as abordagens de tomada de decisão e controle de mudanças definidas pela tarefa Planejar a governança da análise de negócios (p. 37).
Entradas
• Mudança de proposta: pode ser identificada a qualquer momento e afetar qualquer aspecto do trabalho de análise de negócios ou entregáveis concluídos até a data. Há muitos gatilhos para uma mudança proposta, incluindo mudanças na estratégia de negócios, partes interessadas, requisitos legais ou mudanças regulatórias.
• Requisitos: pode precisar ser avaliado para identificar o impacto de uma modificação de proposta.
• Projetos: podem precisar ser avaliados para identificar o impacto de uma modificação de proposta.
Diagrama de Entradas e Saídas de Avaliação de Mudanças dos Requisitos – (Assess Requirements Changes).
Avaliação de mudança de projetos
Avaliação de Mudança de Requisitos
5.4 - Avaliação de Mudanças dos Requisitos
	Entradas
Diretrizes eFerramentasProposta de mudança
Requisitos
Projeto
Estratégia de Mudança
Conhecimento do domínio
Abordagem da Governança
	
Informações Legais / Regulatórias
	SaídaArquitetura dos Requisitos
Escopo da Solução
Elementos
 Formalidade de avaliação
Os analistas de negócios determinarão a formalidade do processo de avaliação com base nas informações disponíveis, na aparente importância da mudança e no processo de governança. Muitas mudanças propostas podem ser retiradas da consideração ou recusadas antes que qualquer aprovação formal seja necessária. Uma abordagem preditiva pode indicar uma avaliação mais formal das mudanças propostas. Em abordagens preditivas, o impacto de cada mudança pode ser perturbador; a mudança pode gerar potencialmente uma reformulação substancial de tarefas e atividades concluídas em atividades anteriores. Uma abordagem adaptativa pode exigir menos formalidade na avaliação das mudanças propostas. Embora possa haver retrabalho necessário como resultado de cada mudança, as abordagens adaptativas tentam minimizar o impacto das mudanças, utilizando técnicas de implementação iterativas e incrementais. Essa ideia de evolução contínua pode reduzir a necessidade de avaliação formal de impacto.
 Análise de impacto
A análise de impacto é realizada para avaliar ou avaliar o efeito de uma mudança.
A rastreabilidade é uma ferramenta útil para realizar a análise de impacto. Quando um requisito muda, seus relacionamentos com outros requisitos ou componentes da solução podem ser revisados. Cada requisito ou componente relacionado também pode exigir uma alteração para suportar o novo requisito.
Ao considerar mudanças ou adições aos requisitos existentes, os analistas de negócios avaliam o impacto da mudança proposta considerando:
• Benefício: o benefício que será obtido ao aceitar a mudança.
• Custo: o custo total para implementar a alteração, incluindo o custo para fazer a alteração, o custo do retrabalho associado e os custos de oportunidade, como o número de outros recursos que podem precisar ser sacrificados ou adiados se a alteração for aprovada.
• Impacto: o número de clientes ou processos de negócios afetados se a alteração for aceita.
• Cronograma: o impacto nos compromissos de entrega existentes, se a alteração for aprovada.
• Urgência: o nível de importância, incluindo os fatores que determinam a necessidade, como questões reguladoras ou de segurança.
 Resolução de Impacto
Dependendo da abordagem planejada, várias partes interessadas (incluindo o analista de negócios) podem ser autorizadas a aprovar, negar ou adiar a alteração proposta. Todos os impactos e resoluções resultantes da análise de mudanças devem ser documentados e comunicados a todas as partes interessadas. A forma como as decisões e mudanças serão tomadas e comunicadas através de uma iniciativa é determinada pela tarefa Plan Business Analysis Governance (p. 37).
Diretrizes e Ferramentas
• Estratégia de Mudança: descreve o propósito e a direção das mudanças, estabelece o contexto para a mudança e identifica os componentes críticos para a mudança.
• Domínio do Conhecimento: o conhecimento e a especialização no domínio do negócio são necessários para avaliar as mudanças propostas nos requisitos.
• Abordagem de governança: fornece orientação sobre os processos de controle de mudanças e tomada de decisões, bem como os papéis das partes interessadas nesse processo.
• Informação Legal / Regulamentar: descreve regras ou regulamentos legislativos que devem ser seguidos. Estes podem afetar os requisitos e devem ser considerados ao fazer alterações.
• Arquitetura de Requisitos: os requisitos podem estar relacionados entre si, portanto, o analista de negócios examina e analisa as relações de requisitos para determinar quais requisitos serão impactados por uma mudança de requisitos solicitada.
• Escopo da solução: deve ser considerado ao avaliar as alterações para entender completamente o impacto de uma alteração proposta.
Técnicas
• Casos de Negócios: usados ​​para justificar uma mudança proposta.
• Análise de Regras de Negócios: usada para avaliar mudanças nas políticas de negócios e nas regras de negócios e desenvolver orientação revisada.
• Análise de Decisão: usada para facilitar o processo de avaliação de mudanças.
• Análise de documentos: usado para analisar documentos existentes que facilitam a compreensão do impacto da mudança.
• Estimativa: usada para determinar o tamanho da mudança.
• Análise Financeira: usada para estimar as consequências financeiras de uma mudança proposta.
• Análise de interface: usada para ajudar analistas de negócios a identificar interfaces que podem ser afetadas pela mudança.
• Entrevistas: usado para obter uma compreensão do impacto sobre a organização ou seus ativos de um único ou pequeno grupo de partes interessadas.
• Rastreamento de itens: usado para rastrear quaisquer problemas ou conflitos descobertos durante a análise de impacto.
• Análise e Gerenciamento de Risco: usado para determinar o nível de risco associado à mudança.
• Workshops: usado para obter uma compreensão do impacto ou para resolver alterações em um ambiente de grupo.
Stakeholders (Partes Interessadas) 
• Cliente: fornece feedback sobre o impacto que a alteração terá sobre o valor.
• Especialista em assunto de domínio: tem experiência em algum aspecto da situação e pode fornecer informações sobre como a mudança afetará a organização e o valor.
• Usuário final: usa a solução ou é um componente da solução e pode oferecer informações sobre o impacto da alteração em suas atividades.
• Suporte operacional: fornece informações sobre a capacidade de suporte à operação da solução e a necessidade de compreender a natureza da alteração na solução para poder suportá-la.
• Gerente de Projeto: analisa a avaliação de mudanças de requisitos para determinar se o trabalho adicional do projeto é necessário para uma implementação bem-sucedida da solução.
• Regulador: as mudanças provavelmente serão referenciadas pelos auditores para confirmar a conformidade com os padrões.
• Patrocinador: responsável pelo escopo da solução e pode fornecer uma visão a ser utilizada ao avaliar a mudança.
• Testador: consultado para estabelecer o impacto das mudanças propostas.
  Saídas
• Avaliação de Mudança de Requisitos: a recomendação para aprovar, modificar ou negar uma mudança proposta aos requisitos.
• Projeto de Avaliação de Mudanças: a recomendação para aprovar, modificar ou negar uma alteração proposta para um ou mais componentes do projeto.
Aprovar os requisitos – (Approve Requirements)
Propósito
A finalidade de Aprovar Requisitos é obter o acordo e a aprovação dos requisitos e projetos para o trabalho de análise de negócios para continuar e / ou a construção da solução para prosseguir.
Descrição
Os analistas de negócios são responsáveis por garantir a comunicação clara de requisitos, projetos e outras informações de análise de negócios aos principais envolvidos responsáveis pela aprovação dessas informações.
A aprovação de requisitos e projetos pode ser formal ou informal.
As abordagens preditivas geralmente executam aprovações no final da fase ou durante as reuniões de controle de mudanças planejadas. As abordagens adaptativas normalmente aprovam os requisitos apenas quando a construção e a implementação de uma solução que atende ao requisito podem ser iniciadas. Os analistas de negócios trabalham com as principais partes interessadas para obter consenso sobre requisitos novos e alterados, comunicar o resultado das discussões e acompanhar e gerenciar a aprovação.
Entradas
• Requisitos (verificados): um conjunto de requisitos que foram verificados como sendo de qualidade suficiente para serem usados como um corpo confiável de trabalho para especificação e desenvolvimento adicionais.
• Projetos: um conjunto de projetos que foram determinados como prontos para serem usados para especificação e desenvolvimento adicionais.
Diagramade Entradas e Saídas da Aprovação dos Requisitos
5.2 – Projetos
(aprovados)
5.2 – Requisitos
 (aprovados) 
5.5 – Aprovação de Requisitos
Projetos
Requisitos
(verificados)
	 Entrada
Diretrizes e FerramentasAlterar projetos de estratégia
Abordagem de Governança
Informações Legais / Regulatórias
Ferramentas de Gerenciamento de Requisitos / Repositório
	SaídaEscopo da Solução
	
Elementos
 Entender as funções das partes interessadas
O processo de aprovação é definido pela tarefa Plan Business Analysis Governance (p. 37). Parte da definição do processo de aprovação é entender os papéis das partes interessadas e os níveis de autoridade. Os analistas de negócios são responsáveis por obter as aprovações das partes interessadas e precisam entender quem detém a responsabilidade pela tomada de decisões e quem possui autoridade para assinar a iniciativa. Os analistas de negócios também consideram todos os interessados influentes que devem ser consultados ou informados sobre os requisitos. Poucos interessados podem ter autoridade para aprovar ou negar mudanças, mas muitas partes interessadas podem influenciar essas decisões.
 Gerenciamento de conflitos e problemas
Para manter o apoio das partes interessadas à solução, geralmente é procurado consenso entre as partes interessadas antes de solicitar a aprovação dos requisitos. A abordagem para determinar como proteger decisões e resolver conflitos em uma iniciativa é planejada na tarefa Planejar a governança de análise de negócios (p. 37).
Grupos de partes interessadas frequentemente têm pontos de vista variados e prioridades conflitantes. Um conflito pode surgir entre as partes interessadas como resultado de diferentes interpretações de requisitos ou projetos e valores conflitantes colocados sobre eles.
O analista de negócios facilita a comunicação entre as partes interessadas em áreas de conflito, para que cada grupo tenha uma apreciação aprimorada das necessidades dos outros. A resolução de conflitos e o gerenciamento de problemas podem ocorrer com bastante frequência, pois o analista de negócios está revisando os requisitos e os projetos, e com o objetivo de garantir a aprovação.
 Consenso de ganho
Os analistas de negócios são responsáveis ​​por garantir que as partes interessadas com autoridade de aprovação entendam e aceitem os requisitos. A aprovação pode confirmar que as partes interessadas acreditam que será criado um valor suficiente para a organização justificar o investimento em uma solução. Os analistas de negócios obtêm aprovação revendo os requisitos ou alterações nos requisitos com os indivíduos ou grupos responsáveis ​​e solicitando que eles aprovem, indicando sua concordância com a solução ou os projetos descritos.
Utilizando os métodos e meios estabelecidos nas tarefas Planejar a Governança de Análise de Negócios (pág. 37) e Comunicar Informações de Análise de Negócios (pág. 67), os analistas de negócios apresentam os requisitos às partes interessadas para aprovação.
Os analistas de negócios facilitam este processo de aprovação, resolvendo quaisquer dúvidas ou fornecendo informações adicionais quando solicitadas. Um acordo completo pode não ser necessário para uma mudança bem-sucedida, mas se houver uma falta de acordo, os riscos associados devem ser identificados e gerenciados de acordo.
 Rastreie e comunique a aprovação
O analista de negócios registra as decisões de aprovação, possivelmente na manutenção de requisitos e nas ferramentas de rastreamento. Para comunicar o status dos requisitos, é necessário manter registros precisos do status de aprovação atual.
As partes interessadas devem ser capazes de determinar quais requisitos e projetos estão atualmente aprovados e em linha para implementação. Pode haver valor na manutenção de um histórico de auditoria de alterações nos requisitos: o que foi alterado, quem fez a alteração, o motivo da alteração e quando ela foi feita.
Diretrizes e Ferramentas
• Estratégia de mudança: fornece informações que auxiliam no gerenciamento do consenso das partes interessadas em relação às necessidades de todas as partes interessadas.
• Abordagem de governança: identifica as partes interessadas que têm autoridade e responsabilidade para aprovar informações de análise de negócios e explica quando essas aprovações ocorrerão e como elas se alinharão às políticas organizacionais.
• Informação Legal / Regulamentar: descreve regras ou regulamentos legislativos que devem ser seguidos. Eles podem afetar o processo de aprovação de requisitos e projetos.
• Ferramentas / Repositório de Gerenciamento de Requisitos: ferramenta para registrar as aprovações de requisitos.
• Escopo da solução: deve ser considerado ao aprovar os requisitos para avaliar com precisão o alinhamento e a integridade.
Técnicas
• Critérios de aceitação e avaliação: usados para definir os critérios de aprovação.
• Análise de decisão: usada para resolver problemas e obter concordância.
• Rastreamento de itens: usado para rastrear problemas identificados durante o processo de acordo.
• Comentários: usado para avaliar os requisitos.
• Workshops: usados para facilitar a obtenção de aprovação.
Stakeholders – (Partes Interessadas) 
• Cliente: pode desempenhar um papel ativo na revisão e aprovação de requisitos e projetos para garantir que as necessidades sejam atendidas.
• Especialista no assunto do domínio: pode estar envolvido na revisão e aprovação de requisitos e projetos definidos pela designação de funções e responsabilidades das partes interessadas.
• Usuário final: pessoas que usam a solução, ou que são um componente da solução, e podem estar envolvidos na revisão, validação e priorização de requisitos e projetos, conforme definido pela designação das funções e responsabilidades das partes interessadas.
• Suporte operacional: responsável por garantir que os requisitos e projetos sejam suportáveis ​​dentro das restrições impostas pelos padrões de tecnologia e pelos planos de capacidade organizacional. O pessoal de suporte operacional pode ter um papel na revisão e aprovação de requisitos.
• Gerente de Projetos: responsável por identificar e gerenciar os riscos associados ao design, desenvolvimento, entrega, implementação, operação e manutenção da solução. O gerente de projeto pode gerenciar as atividades do plano do projeto referentes à revisão e / ou aprovação.
• Regulador: parte externa ou interna que é responsável por fornecer opiniões sobre o relacionamento entre os requisitos declarados e os regulamentos específicos, seja formalmente em uma auditoria ou informalmente como entradas para as tarefas de gerenciamento do ciclo de vida dos requisitos.
• Patrocinador: responsável por revisar e aprovar o business case, solução ou escopo do produto, e todos os requisitos e projetos.
• Testador: responsável por garantir que os padrões de garantia de qualidade sejam viáveis dentro das informações de análise de negócios. Por exemplo, os requisitos têm a característica testável.
Saídas
• Requisitos (aprovados): requisitos que são acordados pelas partes interessadas e estão prontos para uso em esforços subsequentes de análise de negócios.
• Projetos (aprovados): projetos que são acordados pelas partes interessadas e estão prontos para uso em análises subsequentes de negócios ou esforços de desenvolvimento de soluções.