Tópicos

Relacionamento com Outros Planos Para o início da página

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

Organização, Responsabilidades e Interfaces Para o início da página

Conforme descrito em ../../papers/apprmuc.htm -- This hyperlink in not present in this generated websiteWhite 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?

Identificando os Itens de Rastreabilidade Para o início da página

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

Especificando a Rastreabilidade Para o início da página

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 ../../papers/traceability.htm -- This hyperlink in not present in this generated websiteTraceability Strategies for Managing Requirements With Use Case.

Atributos de Amostra Para o início da página

A seguir, alguns atributos de exemplo dos quais você pode desejar selecionar.

Necessidade do Investidor Para o início da página

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 ../workguid/wg_paret.htm -- This hyperlink in not present in this generated websiteDiagrama de Pareto mostrando a contribuição para cada uma das várias Necessidades do Investidor.

Gráfico mostrando o impacto relativo de 5 problemas para a oportunidade geral de negócios

Recursos, Requisitos Suplementares e Casos de Uso Para o início da página

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 Para o início da página

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 Para o início da página

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 Para o início da página

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

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

Selecionando Atributos Para o início da página

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.

Relatórios e Medidas Para o início da página

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.

Gerenciamento de Mudanças de Requisitos Para o início da página

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 Para o início da página

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 Para o início da página

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 Para o início da página

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).



Rational Unified Process   2003.06.15