Relacionamento com Outros Planos

O Plano de Gerenciamento de Requisitos contém informações que podem ser cobertas com maior ou menor extensão por outros planos.

Consulte Produto de Trabalho: Plano de Gerenciamento de Requisitos, Adaptação para orientação de adaptação.

Organização, Responsabilidade e Interfaces

Conforme descrito no Whitepaper: Aplicando o Gerenciamento de Requisitos com Casos de Uso, o gerenciamento de requisitos é importante para assegurar o sucesso do projeto.  As causas de defeito mais comuns citadas do projeto incluem:

• Falta de input do usuário
• Requisitos incompletos
• Requisitos variáveis

Os erros de requisito provavelmente também representam a classe de erro mais comum e a de mais alto custo em termos de correção.

Ter os relacionamentos certos com os investidores poderá ajudar nesse tipo de problema.  Os envolvidos são uma origem de entrada importante para definir requisitos e compreender as prioridades dos requisitos.  No entanto, muitos envolvidos não conseguem perceber os impactos de custo e de planejamento dos recursos solicitados e, portanto, suas expectativas devem ser gerenciadas pela organização de desenvolvimento.

Estabelecer os relacionamentos dos investidores inclui definir:

• Responsabilidades dos investidores: A equipe estará disponível no local para consulta? Em horários predefinidos?
• A visibilidade dos investidores nos produtos de trabalho do projeto: Abrir a visibilidade para todos os produtos de trabalho? Permitir a visibilidade apenas em marcos programados?

Identificando Itens de Rastreabilidade

Descreva os itens de rastreabilidade e defina como eles devem ser nomeados, marcados e numerados. Consulte Conceito: Tipos de Requisitos e Conceito: Rastreabilidade.

Os itens de rastreabilidade mais importantes estão listados na Tarefa: Desenvolver o Plano de Gerenciamento de Requisitos.

Especificando a Rastreabilidade

Uma rastreabilidade típica, com um conjunto limitado de produtos de trabalho essenciais, é descrita na Tarefa: Desenvolver o Plano de Gerenciamento de Requisitos.

Além de identificar os links de rastreabilidade, especifique a cardinalidade deles. Algumas restrições comuns:

• Cada recurso de produto aprovado deve ser vinculado a um ou mais requisitos suplementares, a um ou mais casos de uso ou a ambos.
• Cada requisito suplementar e cada seção de caso de uso deve ser vinculado a um ou mais casos de teste.

Uma discussão mais detalhada sobre rastreabilidade é fornecida no white paper Estratégias de Rastreabilidade para Gerenciar Requisitos com o Caso de Uso.

Atributos de Amostra

A seguir, alguns atributos de exemplo dos quais você pode desejar selecionar, organizados utilizando os tipos de requisitos identificados na Tarefa: Desenvolver o Plano de Gerenciamento de Requisitos.

Necessidade dos Envolvidos

Origem: o investidor que origina o requisito. (Também é possível implementá-la como uma rastreabilidade para um item de rastreabilidade "Envolvido".)

Contribuição: indica a contribuição do problema para a oportunidade geral de negócios ou para o problema sendo identificado pelo projeto. Porcentagem (0 a 100%). A soma de todas as contribuições não deve ultrapassar 100%. A seguir, um exemplo de Diagrama de Pareto mostrando a contribuição para cada uma da várias Necessidades dos Envolvidos.

Recursos, Requisitos Suplementares e Casos de Uso

Status: indica se o requisito foi revisado e aceito pelo "canal oficial". Proposto, Rejeitado, Aprovado são valores de exemplo.

Pode ser um status combinado ou um status definido por um grupo de trabalho capaz de tomar decisões de vinculação.

Benefício: a importância do ponto de vista do(s) envolvido(s).

• Crítico (ou principal). Casos de uso relacionados às principais tarefas do sistema, sua função básica, as funções para as quais está sendo desenvolvido. Se não estiverem presentes, o sistema não conseguirá cumprir sua principal missão. Controlam o design de arquitetura e tendem a ser os casos de uso utilizados com mais freqüência.
• Importante (ou secundário). Casos de uso relacionados a suporte às funções do sistema, como compilação de dados estatísticos, geração de relatórios, supervisão e testes de função. Se não estiverem presentes, o sistema conseguirá ainda (por algum tempo) cumprir sua missão fundamental, mas com uma qualidade de serviço inferior. Na modelagem, sua importância é menor do que os casos de uso críticos
• Útil (recomendável). São recursos que "auxiliam", não vinculados à principal missão do sistema, mas que ajudam em seu uso ou posicionamento no mercado.

Esforço: estimativa em dias de esforço para implementar o requisito.

Por exemplo, as categorias poderiam ser Baixo, Médio, Alto. Se for Baixo = < 1 dia, Médio = 1 a 20 dias, Alto = >20 dias.

Ao definir o Esforço, indique claramente quais sobrecargas (esforço de gerenciamento, esforço de teste, esforço de requisitos, etc.) serão incluídas na estimativa.

Tamanho: SLOCs (Linhas de Código Fonte) estimadas sem comentários, excluindo qualquer código de teste.

É possível que você deseje distinguir entre SLOCs novas e reutilizadas para calcular melhor as estimativas de custo.

Risco: porcentagem de probabilidade da implementação do requisito encontrar eventos indesejáveis significativos, como não cumprimento do planejamento, overrun do custo ou cancelamento.

Por exemplo, as categorias poderiam ser Baixo, Médio, Alto.   Se for Baixo = <10%, Médio = 10 a 50%, Alto = >50%.

Uma outra opção para Risco é controlar separadamente o Risco de Tecnologia - porcentagem de probabilidade de enfrentar sérias dificuldades ao implementar o requisito devido à falta de experiência no domínio e/ou nas tecnologias necessárias.  Desse modo, o risco total pode ser calculado como uma soma ponderada com base em outros atributos, incluindo tamanho, esforço, estabilidade, risco de tecnologia, impacto arquitetural e complexidade organizacional.

Complexidade Organizacional: categorização do controle sobre a organização que desenvolve o requisito.

• Interna: desenvolvimento interno em um site
• Geográfica: equipe distribuída geograficamente
• Externa: organização externa dentro da empresa.  
• Fornecedor: subcontrato ou aquisição de um software desenvolvido externamente.

Impacto Arquitetural: indica como esse requisito afetará a arquitetura de software.

• Nenhum: não afeta a arquitetura existente.
• Estende: requer a extensão da arquitetura existente.
• Modifica: a arquitetura existente deve ser alterada para acomodar o requisito.  

Estabilidade: probabilidade de esse requisito ser alterado ou de ocorrer alteração na compreensão do requisito pelas equipes de desenvolvimento. (>50% = Alta, 10..50% = Média, <10%=Baixa)

Liberação de Destino: a liberação planejada do produto no qual o requisito será atendido. (Liberação1, Liberação1.1, Liberação2, ...)

Nível / Critério de Risco: possibilidade de afetar o funcionamento, o bem-estar ou de trazer conseqüências econômicas, geralmente como resultado da falha do software de desempenhar conforme necessário.

• Insignificante: não pode resultar em lesões corporais sérias ou em danos significativos no equipamento.
• Marginal: pode ser controlado sem causar lesões corporais ou danos graves ao sistema.
• Crítica: pode causar lesões corporais ou danos graves ao sistema ou necessitará de ação corretiva imediata para a sobrevivência do pessoal ou do sistema.
• Catastrófica: pode causar sérias lesões corporais, morte ou perda completa do sistema.

Os riscos também podem ser identificados como tipos de requisitos separados e vinculados aos casos de uso associados.  Também é possível que você deseje controlar a probabilidade de riscos, as ações corretivas e/ou as medidas preventivas.

Interpretação: em alguns casos em que os requisitos formam um contrato formal, talvez seja difícil e dispendioso alterar o texto referente a eles.  Quando um requisito torna-se mais compreensível na organização de desenvolvimento, é possível que haja a necessidade de anexar um texto de interpretação, em vez de simplesmente alterar o texto oficial do requisito.

Caso de Uso

Além do que foi dito acima, convém também controlar o seguinte atributo de caso de uso:

%Detailed: grau de elaboração do Caso de Uso:

• 10%: é fornecida uma descrição básica.
• 50%: os fluxos principais são documentados.
• 80%: concluído, mas não revisado. Todas as precondições e pós-condições são totalmente especificadas.
• 100%: revisado e aprovado.

Caso de Teste

Status: controla o progresso durante o desenvolvimento do teste.

• Sem Atividade: nenhum trabalho é realizado no desenvolvimento desse caso de teste.
• Manual: um script manual foi criado e validado como capaz de verificar os requisitos associados.
• Automatizado: um script automatizado foi criado e validado como capaz de verificar os requisitos associados.

Atributos Gerais

Estes são alguns outros atributos de requisito com aplicabilidade geral:

• Iteração Planejada
• Iteração Real
• Parte Responsável

Selecionando Atributos

Os atributos são utilizados para controlar informações associadas a um item de rastreabilidade, normalmente para fins de status e geração de relatórios.  Cada organização pode requerer informações de controle específicas exclusivas à sua organização.  Antes de designar um atributo, considere o seguinte:

• Quem fornecerá essas informações?
• Quem utilizará essas informações e por que elas são úteis?
• O custo para controlar essas informações compensa o benefício?

Os atributos essenciais a serem controlados são Risco, Benefício, Esforço, Estabilidade e Impacto Arquitetural para permitir a priorização de requisitos para gerenciamento do escopo e para designar requisitos a iterações. Eles devem ser controlados inicialmente em Recursos e, posteriormente, em todos os Casos de Uso e Requisitos Suplementares.

Consideração sobre as Informações Obtidas

Além de utilizar os atributos de requisitos diretamente, é possível que você deseje obter informações desses atributos de requisitos por meio da rastreabilidade feita em outros tipos de requisitos. Estes são alguns padrões típicos utilizados para obter informações:

• Derivação Descendente - de acordo com a rastreabilidade anterior, suponha que um Recurso de Produto tenha um atributo "Liberação de Destino". Seria possível deduzir que cada Seção de Caso de Uso rastreada por esse Recurso de Produto também estaria disponível antes ou na Liberação de Destino especificada.
• Derivação Ascendente - de acordo com a rastreabilidade anterior, suponha que uma Sessão de Caso de Uso tenha um atributo "Esforço Estimado". O custo de um Recurso de Produto pode ser estimado através da soma do Esforço Estimado para as Seções de Casos de Uso rastreadas. Tome cuidado, pois vários Recursos de Produto poderiam mapear para a mesma Seção de Caso de Uso.

Portanto, para atribuir atributos a tipos de requisitos, considere o seguinte:

• Quais informações/relatórios obtidos você deseja gerar a partir deste atributo?
• Em qual nível na hierarquia de rastreabilidade este atributo deve ser controlado?

Dependência dos Atributos

Alguns atributos só podem ser aplicáveis a um determinado nível de desenvolvimento. Por exemplo, um atributo de esforço estimado para um caso de uso poderá ser substituído pelas estimativas de esforço nos elementos do design quando o caso de uso estiver totalmente representado no design.

Relatórios e Medidas

A seguir, exemplos de relatórios e medidas relacionados a requisitos. Selecione o conjunto necessário/desejado de relatórios e medidas para o projeto a fim de obter os atributos necessários ao Plano de Gerenciamento de Requisitos.

Gerenciamento de Mudanças de Requisitos

A alteração é inevitável e deve ser planejada. As mudanças ocorrem porque:

• Houve uma alteração no problema a ser resolvido. Isso se deve a novas regulamentações, pressões econômicas, mudanças tecnológicas etc.
• Os investidores mudaram a maneira de pensar ou perceber o que querem que o sistema faça. Várias causas podem ter sido responsáveis por isso, incluindo mudanças na equipe responsável, uma compreensão maior dos problemas etc.
• Falha na inclusão de todos os investidores ou ao fazer as perguntas certas durante a definição dos requisitos originais.

Estratégias para gerenciar requisitos variáveis:

• Criar uma Baseline dos Requisitos
• Estabelecer um Único Canal para Controle de Mudanças
• Manter um Histórico de Mudanças

Criar uma Linha de Base dos Requisitos

Quase no final da fase de elaboração, o Analista de Sistemas deverá criar uma baseline de todos os requisitos conhecidos. Geralmente, isso é desempenhado assegurando que exista controle de versão nos produtos de trabalho de requisitos e identificando o conjunto de produtos de trabalho e suas versões que formam a linha de base.

A finalidade da baseline não é a de tornar os requisitos pendentes. Na verdade, é ativar requisitos novos e modificados para que sejam identificados, comunicados, estimados e controlados.

Consulte também Mentor de Ferramenta: Criando a Linha de Base de um Projeto Rational RequisitePro.

Estabelecer um Único Canal para Controle de Mudanças

O desejo de alteração de um investidor não pode ser assumido como o de alterar oficialmente o orçamento e o planejamento. Normalmente, um processo de negociação ou de reconciliação de orçamento deve ser iniciado antes da aprovação de uma alteração. As mudanças devem ser equilibradas com freqüência.

É crucial que cada alteração passe por um único canal, o CCB (Conselho de Controle de Mudanças), para determinar seu impacto no sistema e para passar por aprovação oficial. O mecanismo para propor uma alteração consiste em submeter um Controle de Mudanças, que é revisado pelo CCB.

Para obter informações adicionais, consulte Tarefa: Estabelecer o Processo de Controle de Mudanças.

Manter um Histórico de Mudanças

Convém manter uma trilha de auditoria de mudanças para requisitos individuais. Esse histórico de mudanças permite a visualização de todas as mudanças anteriores feitas no requisito, bem como as mudanças aos valores de atributos, além dos fundamentos da alteração. Ele pode ser útil para avaliar a estabilidade real dos requisitos e para identificar casos em que o processo de controle de mudanças talvez não esteja funcionando (por exemplo, identificando mudanças nos requisitos que não foram revistas e aprovadas apropriadamente).