Diretrizes: Plano de Gerenciamento de Requisitos
Tópicos
O Plano de Gerenciamento de Requisitos contém informações que podem ser cobertas
com maior ou menor extensão por outros planos.
Conforme descrito em White Paper: Applying
Requirements Management with Use Cases, o gerenciamento de requisitos é importante
para assegurar 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 investidores poderá ajudar nesse tipo de problema.
Os investidores são uma origem de entrada importante para definir requisitos e entender
suas prioridades de requisitos. No entanto, vários investidores 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 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.
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 artigo Traceability
Strategies for Managing Requirements With Use Case.
A seguir, alguns atributos de exemplo dos quais você pode desejar selecionar.
Necessidade do Investidor
Origem: O investidor que origina o requisito. (Também é
possível implementá-la como uma rastreabilidade para um item de rastreabilidade
"Investidor".)
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 das várias Necessidades do Investidor.

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)
investidor(es).
- 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-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 ser de 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-50%, Alto = >50%.
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 na arquitetura
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 na Arquitetura: 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 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 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:
Porcentagem de Detalhe: 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
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 na Arquitetura 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.
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.
Descrição do Relatório/Medida |
Utilizado 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). |
Podem ser listas classificadas separadamente ou uma única lista classificada
por uma combinação ponderada desses atributos. Utilizada para Atividade:
Priorizar Casos de Uso. |
Porcentagem de Recursos em cada Categoria de Status. |
Controla o andamento durante a definição da baseline do projeto.
|
- classificada pela Liberação de Destino |
- controla o progresso por liberação |
- ponderada pelo Esforço |
- fornece uma medida de progresso mais precisa. |
Recursos classificados pelo Risco |
- identifica os recursos de risco. Útil para gerenciar
o escopo e para designar recursos a iterações. |
- classificados pela Liberação de Destino, com Risco de Desenvolvimento
somado para cada Liberação de Destino |
- útil para avaliar se os recursos de risco foram
planejados cedo ou tarde no projeto. |
Seções de Casos de Uso classificadas por Estabilidade |
- utilizadas para decidir quais seções de casos de uso precisam ser estabilizadas. |
- ponderadas ou classificadas pelas Influências da Arquitetura |
- útil para 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 designe
imediatamente todos os atributos (por exemplo, utilizando um valor "Indefinido"
padrão). Pontos de verificação:
Especificação de Requisitos de Software utiliza esse relatório para procurar
esses atributos indefinidos. |
Itens de Rastreabilidade com links de rastreabilidade incompletos |
Um relatório de links de rastreabilidade incorretos ou incompletos é
utilizado para Pontos de Verificação: Especificação de
Requisitos de Software. |
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 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 é a de tornar os requisitos pendentes. Na verdade, é
ativar requisitos novos e modificados para que sejam identificados, comunicados, estimados
e controlados.
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 proposta de uma alteração é enviar
um Controle de Mudanças, que é revisado
pelo CCB.
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).
|