Diretrizes: Plano de Gerenciamento de Requisitos
Tópicos
O Plano de Gerenciamento de Requisitos contém informações que podem ser abordadas mais ou menos detalhadamente por outros planos. Consulte o Artefato: Adaptação ao Plano de Gerenciamento de Requisitos para obter uma diretriz de adaptação.
Conforme descrito no Artigo: Applying Requirements Management with Use Cases, o gerenciamento de requisitos é importante para garantir o sucesso do projeto. As causas de falha do projeto citadas com mais freqüência 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 envolvidos poderá ajudar nesse tipo de problema. Os envolvidos são uma fonte de input importante para definir requisitos e entender suas prioridades. No entanto, vários envolvidos não conseguem perceber os impactos de custo e de programação das características solicitadas e, portanto, suas expectativas devem ser gerenciadas pela organização de desenvolvimento.
Estabelecer os relacionamentos dos envolvidos inclui definir:
- As responsabilidades dos envolvidos: A equipe estará disponível no local para serem consultados? Em horários predefinidos?
- A visibilidade dos envolvidos nos artefatos do projeto: Abrir a visibilidade para todos os artefatos? Permitir a visibilidade apenas em marcos programados?
Descreva os itens de rastreabilidade e defina como eles devem ser nomeados, marcados e numerados. Consulte Conceitos: Tipos de Requisitos e Conceitos: Rastreabilidade. Os itens de rastreabilidade mais importantes estão listados em Atividade: Desenvolver um Plano de Gerenciamento de Requisitos.
Uma rastreabilidade típica, com um conjunto limitado de artefatos essenciais, é descrita em Atividade: Desenvolver um Plano de Gerenciamento de Requisitos.
Além de identificar os links de rastreabilidade, especifique a cardinalidade deles. Algumas restrições comuns:
- Cada característica de produto aprovada deve ser vinculada 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 Artigo: Traceability Strategies for Managing Requirements With Use Case.
A seguir são apresentados alguns atributos de exemplo para seleção, organizados usando os tipos de requisitos identificados em Atividade: Desenvolver um Plano de Gerenciamento de Requisitos.
Necessidade dos Envolvidos
Origem: Os envolvidos que originam o requisito. (Também pode ser implementado como rastreabilidade para o item de rastreabilidade "Envolvidos").
Contribuição: Indica a contribuição para a oportunidade geral de negócio ou para o problema tratado no projeto. Porcentagem (0 a 100%). A soma de todas as contribuições não deve ultrapassar 100%. O exemplo a seguir de um Diagrama de Pareto mostra a contribuição para cada uma das diversas Necessidades dos Envolvidos.
Características, Requisitos Suplementares e Casos de Uso
Status: Indica se o requisito foi revisto 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 dos envolvidos.
- Críticos (ou principais). 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.
- Importantes (ou secundários). 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
- Úteis (recomendável). São características que "auxiliam" e que não estão vinculadas à principal missão do sistema, mas que ajudam na utilização do sistema ou em seu 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.
Quando definir o Esforço, indique claramente quais cargas (esforço de gerenciamento, esforço de teste, esforço de requisitos etc.) serão incluídos na estimativa.
Tamanho: Linhas estimadas de código-fonte (SLOCs), sem ser de comentários e excluindo qualquer código de teste.
Convém fazer a distinção entre as SLOCs novas e as reutilizadas para poder calcular melhor as estimativas de custo.
Risco: Porcentagem de probabilidade de, durante a implementação do requisito, apresentar eventos indesejáveis significativos, como não cumprimento da programação, orçamento de custo ultrapassado ou cancelamento.
As categorias podem ser, por exemplo, Baixa, Média, Alta. Nesse caso, as porcentagens seriam: Baixa = <10%, Média = 10 a 50%, Alta = >50%.
Uma outra opção para Risco seria controlar separadamente o Risco de Tecnologia - porcentagem de probabilidade de enfrentar sérias dificuldades durante a implementação do requisito devido à falta de experiência no domínio e/ou nas tecnologias necessárias. Desse modo, o risco total poderia ser calculado como uma soma ponderada baseada em outros atributos, incluindo tamanho, esforço, estabilidade, risco de tecnologia, impacto na arquitetura e complexidade organizacional.
Complexidade Organizacional: Categorização do controle da organização que desenvolve o requisito.
- Interna: Desenvolvimento interno em um local
- Geográfica: Equipe distribuída geograficamente
- Externa: Organização externa dentro da empresa.
- Fornecedor: Subcontrato ou aquisição de um software desenvolvido externamente.
Impacto na Arquitetura: Indica como será o impacto deste requisito na 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 uma mudança na compreensão do requisito pelas equipes de desenvolvimento. (>50% = Alta, 10 a 50% = Média, <10% = Baixa)
Release-alvo: É o release planejado do produto no qual o requisito é atendido. (Release1, Release1.1, Release2, ...)
Nível de Risco/Criticalidade: Possibilidade de afetar a saúde, o bem-estar ou de trazer conseqüências econômicas, geralmente como resultado de falha do software, que não é executado conforme o esperado.
-
Insignificante: Não pode resultar em sérias lesões corporais ou danos significativos no equipamento.
-
Marginal: Pode ser controlado sem causar lesões corporais ou danos graves ao sistema.
-
Crítico: Pode causar lesões corporais ou danos graves ao sistema ou, então, necessitará de ação corretiva imediata para a sobrevivência da equipe ou do sistema.
-
Catastrófico: 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. É recomendável também controlar a probabilidade de riscos, as ações corretivas e/ou as medidas preventivas.
Interpretação: Em alguns casos em que os requisitos fazem parte de 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 do desenvolvimento, algumas vezes é necessário 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:
% de Detalhamento: 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 andamento durante o desenvolvimento do teste.
-
Nenhuma Atividade: Nenhum trabalho é executado durante o desenvolvimento deste 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
Os atributos são usados para controlar informações associadas a um item de rastreabilidade, geralmente para fins de status e geração de relatórios. Cada organização pode necessitar de informações de controle específicas e exclusivas. Antes de atribuir um atributo, considere o seguinte:
- Quem fornecerá essas informações?
- Quem usará 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 na Arquitetura, para permitir a priorização de requisitos para gerenciamento do escopo e atribuir requisitos a iterações. Eles devem ser controlados inicialmente em Características e posteriormente em todos os Casos de Uso e Requisitos Suplementares.
Consideração sobre as Informações Obtidas
Além de usar diretamente os atributos dos requisitos, você talvez deseje obter informações sobre esses atributos por meio da rastreabilidade executada em outros tipos de requisitos. Estes são alguns padrões típicos usados para obter informações:
- Derivação Descendente - De acordo com a rastreabilidade acima, suponha que uma Característica de Produto tenha o atributo "Release-alvo". Seria possível deduzir que cada Seção de Caso de Uso rastreada por essa Característica de Produto também estaria disponível antes ou no Release-alvo especificado.
- Derivação Ascendente - De acordo com a rastreabilidade acima, suponha que uma Característica de Produto tenha o atributo "Esforço Estimado". O custo de uma Característica 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árias Características 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.
Os exemplos a seguir mostram relatórios e medidas relacionadas 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.
| Descrição de Relatórios/Métricas |
Usado Para
|
| Prioridade de Desenvolvimento de Casos de Uso (lista de Casos de Uso classificados por Risco, Benefício, Esforço, Estabilidade e Impacto na Arquitetura). |
Pode ser uma única lista classificada por uma combinação ponderada desses atributos ou listas classificadas separadamente. Usadas para Atividade: Priorizar Casos de Uso. |
| Porcentagem de Características em cada Categoria de Status. |
Controlar o andamento durante a definição da baseline do projeto. |
| - classificada pelo Release-alvo |
- controlar o andamento por release |
| - ponderada pelo Esforço |
- fornecer uma métrica de andamento mais precisa. |
| Características classificadas por Risco |
- identificar as características de risco. Útil para gerenciar o escopo e para atribuir características a iterações. |
| - classificadas pelo Release-alvo, com Risco de Desenvolvimento somado para cada Release-alvo |
- avaliar se as características de risco foram programadas cedo ou tarde no projeto. |
| Seções de Casos de Uso classificadas por Estabilidade |
- decidir quais seções de casos de uso precisam ser estabilizadas. |
| - ponderadas ou classificadas pelas Influências da Arquitetura |
- priorizar os casos de uso significativos do ponto de vista da arquitetura e/ou de grande esforço que devem ser estabilizados primeiro. |
| Requisitos com Atributos Indefinidos |
Quando os requisitos são propostos pela primeira vez, é possível que você não atribua imediatamente todos os atributos (por exemplo, usando um valor "Indefinido" padrão). A seção Pontos de Verificação: Especificação dos Requisitos de Software usa esse relatório para procurar por esses atributos indefinidos. |
| Itens de Rastreabilidade com links de rastreabilidade incompletos |
Um relatório de links de rastreabilidade incorretos ou incompletos é usado para Pontos de Verificação: Especificação dos Requisitos de Software. |
Outros relatórios:
Consulte Visão Geral de Relatórios para obter mais detalhes.
A mudança é inevitável e deve ser planejada. As mudanças ocorrem porque:
- Houve mudança no problema a ser solucionado. Isso se deve a novas regulamentações, pressões econômicas, mudanças tecnológicas etc.
- Os envolvidos mudaram a maneira de pensar ou perceber o sistema. 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 envolvidos, 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 Baseline dos Requisitos
Quase no final da fase de elaboração, o Analista de Sistemas deverá criar uma baseline de todos os requisitos conhecidos. Geralmente, esse procedimento é executado verificando se existe controle de versão nos artefatos dos requisitos e identificando o conjunto de artefatos e suas versões que formam a baseline.
A finalidade da baseline não é congelar os requisitos. Na verdade, ela tem como objetivo permitir que requisitos novos e modificados sejam identificados, comunicados, estimados e controlados.
Consulte também Mentor de Ferramentas: Criação de uma Baseline de um Projeto do Rational RequisitePro.
Estabelecer um Único Canal para Controle de Mudanças
O desejo dos envolvidos por mudanças não pode ser o de modificar oficialmente o orçamento e a programação. Em geral, um processo de negociação ou de reconciliação orçamentária deve ser iniciado antes da aprovação de uma mudança. As mudanças devem ser equilibradas com freqüência.
É crucial que cada mudança passe por um único canal, o Comitê de Controle de Mudança (CCB), para determinar seu impacto no sistema e para que a mudança seja submetida a uma aprovação oficial. Consulte Atividade: Estabelecer um Processo de Controle de Mudanças. O mecanismo para proposta de uma mudança consiste em enviar uma Solicitação de Mudança que será revista pelo CCB.
Manter um Histórico de Mudanças
Convém manter uma trilha de auditoria das mudanças realizadas em requisitos individuais. Esse histórico permitirá visualizar todas as mudanças anteriores feitas no requisito, bem como as mudanças realizadas nos valores de atributo, além dos fundamentos da mudança. 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).
Copyright
(c) 1987 - 2001 Rational Software Corporation
| 
