Sistema de Paginação de Esportes Universitários

Plano de Gerenciamento de Requisitos
 
 

Versão 1.0


 



 
 

Histórico da Revisão


Data
Versão
Descrição
Autor
2 de julho de 2000
1.0
Liberação Inicial
Integração de Contexto


Índice Analítico
 
 

1.Introdução

1.1Finalidade

1.2Escopo

1.3Definições, Acrônimo e Abreviações

1.4Referências

2.Gerenciamento de Requisitos

2.1Organização, Responsabilidades e Interfaces

2.2Ferramentas, Ambiente e Infra-estrutura

3.Programa de Gerenciamento de Requisitos

3.1Identificação de Requisitos

3.2Rastreabilidade

Critérios para FEAT

Critérios para NEED

Critérios para UC

Critérios para SUPP

3.3Atributos

Atributos para FEAT

Atributos para NEED

Atributos para UC

Atributos para SUPP

3.4Relatórios e Medidas

3.5Gerenciamento de Mudanças de Requisitos

3.6       Fluxos de Trabalho e Atividades

4.Marcos

5.Treinamento e Recursos
 


Plano de Gerenciamento de Requisitos

1. Introdução

1.1 Finalidade

Este documento descreve as diretrizes utilizadas pelo projeto CSPS (Collegiate Sports Paging System) para estabelecer os documentos de requisitos, tipos de requisitos, atributos de requisitos e a rastreabilidade para gerenciar seus requisitos de projeto de software. Ele também servirá como documento de configuração para a ferramenta de gerenciamento de requisitos Rational RequisitePro.

1.2 Escopo

Esse plano pertence a todas as fases do projeto.

1.3 Definições, Acrônimos e Abreviações

Consulte o Glossário

1.4 Referências

Plano de Desenvolvimento de Software do SPEU
Caso de Desenvolvimento do SPEU 

Plano de Medida do SPEU 

Plano de Gerenciamento de Configuração do SPEU

2. Gerenciamento de Requisitos

2.1 Organização, Responsabilidades e Interfaces

Consulte o Plano de Desenvolvimento de Software do SPEU.

2.2 Ferramentas, Ambiente e Infra-estrutura

O Rational RequisitePro será utilizado para gerenciar os requisitos.   Para obter outras informações sobre a infra-estrutura e o ambiente, consulte o Plano de Desenvolvimento de Software do SPEU.

3. Programa de Gerenciamento de Requisitos

3.1 Identificação de Requisitos

 
Artefato (Tipo de Documento)
Tipo de Requisito
Descrição
VIS (Visão)
NEED (Necessidade dos Envolvidos)
Necessidade Chave do Usuário ou do Envolvido
VIS (Visão)
FEAT (Recurso)
Condições ou recursos dessa liberação do sistema
Modelo de Casos de Uso
UC (Caso de Uso)
Os casos de uso para essa liberação, documentados no Rational Rose, com detalhes no Rational RequisitePro.
SS (Especificação Suplementar)
SUPP (Requisito Suplementar)
Requisitos não funcionais que não foram capturados no modelo de caso de uso
Tabela 3.1-1 Artefatos e Tipos de Requisitos

3.2 Rastreabilidade

Identificados no Conteúdo Abaixo

Figura -1 - Diagrama de Rastreabilidade

Critérios para FEAT

Os recursos serão rastreados para os casos de uso.

Critérios para NEED

As necessidades do usuário serão rastreadas para os FEAT (recursos).  Quaisquer necessidades não rastreadas para um FEAT não serão implementadas.

Critérios para UC

Os casos de uso serão rastreados para os casos de teste.

Critérios para SUPP

As especificações suplementares serão rastreadas para os casos de teste.

3.3 Atributos

Atributos para FEAT

Status
Configurado após a negociação e revisado pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da linha de base do projeto.

 
Proposto
Utilizado para descrever os recursos que estão em discussão, mas que ainda não foram revisados e aceitos pelo "canal oficial", como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento do produto e comunidade de usuários ou clientes.
Aprovado
Recursos que são considerados úteis e viáveis e que foram aprovados para implementação do canal oficial.
Incorporado
Recursos incorporados na linha de base do produto em um período específico.

Benefício

Configurado pelo Marketing, o gerente do produto ou o analista de negócios. Todos os requisitos não são criados de forma igual. Os requisitos de posição segundo seus benefícios relativos ao usuário abrem um diálogo com clientes, analistas e membros da equipe de desenvolvimento. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.
 
Crítico
Recursos essenciais. A falha na implementação significa que o sistema não atenderá às necessidades do cliente. Todos os recursos críticos devem ser implementados na liberação ou o planejamento poderá falhar.
Importante
Recursos importantes para a efetividade e a eficácia do sistema para a maioria dos aplicativos. A funcionalidade não pode ser facilmente fornecida de alguma outra forma. A falta da inclusão de um recurso importante pode afetar a satisfação do cliente ou do usuário ou mesmo a receita, mas não atrasará a liberação.
Útil
Os recursos que são úteis em aplicativos menos comuns serão utilizados com menos freqüência ou para os quais podem ser alcançadas soluções alternativas razoavelmente eficientes. Nenhum impacto significativo na receita ou na satisfação do cliente pode ser esperado se esse item não estiver incluído em uma liberação.

Esforço

Configurado pela equipe de desenvolvimento. Como alguns recursos requerem mais tempo e recursos que outros, estimar o número de equipe ou semanas de pessoas, as linhas de código requeridas ou os pontos de função, por exemplo, é a melhor maneira de calibrar a complexidade e configurar as expectativas daquilo que pode ou não pode ser feito em um determinado período específico. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.  

Risco

Configurado pela equipe de desenvolvimento com base na probabilidade de o projeto passar por eventos indesejáveis, como overruns de custo, atrasos no planejamento ou mesmo cancelamento. A maioria dos gerentes de projetos considera a categorização dos riscos como suficientemente alta, média ou baixa, embora outras gradações sejam possíveis. O risco geralmente pode ser avaliado indiretamente, medindo a incerteza (faixa) da estimativa de planejamento das equipes dos projetos.  

Estabilidade

Configurada pelo analista e equipe de desenvolvimento com base na probabilidade de o recurso ser alterado ou o entendimento da equipe do recurso ser alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos. 

Liberação de Destino

Registra a versão do produto desejada na qual o recurso aparecerá primeiro. Esse campo pode ser utilizado para alocar os recursos a partir de um documento de Visão em uma liberação específica de linha de base. Quando combinado ao campo de status, a sua equipe pode propor, registrar e discutir diversos recursos da liberação sem confirmá-los no desenvolvimento. Serão implementados penas os recursos cujo Status é configurado como Incorporado e cuja Liberação de Destino é definida. Quando ocorrer o gerenciamento do escopo, o Número da Versão da Liberação de Destino pode ser aumentado para que o item permaneça no documento de Visão, mas será liberado posteriormente. 

Designado Para

Em vários projetos, os recursos serão designados às "equipes de recursos" responsáveis pela extração adicional, gravando os requisitos de software e implementação. Essa simples lista suspensa ajudará a todos da equipe do projeto a entenderem melhor as responsabilidades.  

Razão

Esse campo de texto é utilizado para rastrear a origem do recurso solicitado. Os requisitos existem para razões específicas. Esse campo registra uma explicação ou uma referência a uma explicação. Por exemplo, a referência pode ser a uma página ou número de linha de uma especificação de requisito do produto ou a um marcador de minutos em um vídeo de uma importante entrevista com o cliente.

Atributos para NEED

Status
Configurado após a negociação e revisado pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da linha de base do projeto.

 
Proposto
Utilizado para descrever as necessidades que estão em discussão, mas que ainda não foram revisadas e aceitas pelo "canal oficial", como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento do produto e comunidade de usuários ou clientes.
Aprovado
Recursos que são considerados úteis e viáveis e que foram aprovados para implementação do canal oficial.
Incorporado
Necessidades sendo atendidas pela linha de base do produto em período específico.

Esforço

Configurado pela equipe de desenvolvimento. Como algumas necessidades requerem mais tempo e recursos que outras, estimar o número de equipe ou semanas de pessoas, as linhas de código requeridas ou os pontos de função, por exemplo, é a melhor maneira de calibrar a complexidade e configurar as expectativas daquilo que pode ou não pode ser feito em um determinado período de tempo. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.  

Risco

Configurado pela equipe de desenvolvimento com base na probabilidade de o projeto passar por eventos indesejáveis, como overruns de custo, atrasos no planejamento ou mesmo cancelamento. A maioria dos gerentes de projetos considera a categorização dos riscos como suficientemente alta, média ou baixa, embora outras gradações sejam possíveis. O risco geralmente pode ser avaliado indiretamente, medindo a incerteza (faixa) da estimativa de planejamento das equipes dos projetos.  

Estabilidade

Configurada pelo analista e equipe de desenvolvimento com base na probabilidade de a necessidade ser alterada ou o entendimento da equipe da necessidade ser alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos. 

Liberação de Destino

Registra a versão do produto desejada na qual a necessidade será atendida primeiro. Esse campo pode ser utilizado para alocar os recursos a partir de um documento de Visão em uma liberação específica de linha de base. Quando combinado ao campo de status, a sua equipe pode propor, registrar e discutir diversos recursos da liberação sem confirmá-los no desenvolvimento. Serão atendidas apenas as necessidades cujo Status é configurado como Incorporado e cuja Liberação de Destino é definida. Quando ocorrer o gerenciamento do escopo, o Número da Versão da Liberação de Destino pode ser aumentado para que o item permaneça no documento de Visão, mas será liberado posteriormente. 

Razão

Esse campo de texto é utilizado para rastrear a origem da necessidade. Os requisitos existem para razões específicas. Esse campo registra uma explicação ou uma referência a uma explicação. Por exemplo, a referência pode ser a uma página ou número de linha de uma especificação de requisito do produto ou a um marcador de minutos em um vídeo de uma importante entrevista com o cliente.

Atributos para UC

Status
Configurado após a negociação e revisado pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da linha de base do projeto.

 
Proposto
Utilizado para descrever os casos de uso que estão em discussão, mas que ainda não foram revisados e aceitos pelo "canal oficial", como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento do produto e comunidade de usuários ou clientes.
Aprovado
Os casos de uso que são considerados úteis e viáveis e que foram aprovados para implementação do canal oficial.
Incorporado
Casos de uso incorporados na linha de base do produto em um período específico.

Benefício

Configurado pelo Marketing, o gerente do produto ou o analista de negócios. Todos os requisitos não são criados de forma igual. Os casos de uso de posição segundo seus benefícios relativos ao usuário abrem um diálogo com clientes, analistas e membros da equipe de desenvolvimento. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.
 
Crítico
Casos de uso essenciais. A falha na implementação significa que o sistema não atenderá às necessidades do cliente. Todos os casos de uso críticos devem ser implementados na liberação ou o planejamento poderá falhar.
Importante
Os casos de uso importantes para a efetividade e a eficácia do sistema para a maioria dos aplicativos. A funcionalidade não pode ser facilmente fornecida de alguma outra forma. A falta da inclusão de um recurso importante pode afetar a satisfação do cliente ou do usuário ou mesmo a receita, mas não atrasará a liberação.
Útil
Os casos de uso que são úteis em aplicativos menos comuns serão utilizados com menos freqüência ou para os quais podem ser alcançadas soluções alternativas razoavelmente eficientes. Nenhum impacto significativo na receita ou na satisfação do cliente pode ser esperado se esse item não estiver incluído em uma liberação.

Esforço

Configurado pela equipe de desenvolvimento. Como alguns casos de uso requerem mais tempo e recursos que outros, estimar o número de equipe ou semanas de pessoas, as linhas de código requeridas ou os pontos de função, por exemplo, é a melhor maneira de calibrar a complexidade e configurar as expectativas daquilo que pode ou não pode ser feito em um determinado período de tempo. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.  

Risco

Configurado pela equipe de desenvolvimento com base na probabilidade de o projeto passar por eventos indesejáveis, como overruns de custo, atrasos no planejamento ou mesmo cancelamento. A maioria dos gerentes de projetos considera a categorização dos riscos como suficientemente alta, média ou baixa, embora outras gradações sejam possíveis. O risco geralmente pode ser avaliado indiretamente, medindo a incerteza (faixa) da estimativa de planejamento das equipes dos projetos.  

Estabilidade

Configurada pelo analista e equipe de desenvolvimento com base na probabilidade de o caso de uso ser alterado ou o entendimento da equipe do caso de uso ser alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos. 

Liberação de Destino

Registra a versão do produto desejada na qual o caso de uso aparecerá primeiro. Esse campo pode ser utilizado para alocar os casos de uso a partir de um documento de Visão em uma liberação específica de linha de base. Quando combinado ao campo de status, a sua equipe pode propor, registrar e discutir diversos casos de uso da liberação sem confirmá-los no desenvolvimento. Serão implementados apenas os casos de uso cujo Status é configurado como Incorporado e cuja Liberação de Destino é definida. Quando ocorrer o gerenciamento do escopo, o Número da Versão da Liberação de Destino pode ser aumentado para que o item permaneça no documento de Visão, mas será liberado posteriormente. 

Designado Para

Em vários projetos, os casos de uso serão designados às equipes responsáveis pela extração adicional, gravando os requisitos de software e a implementação. Essa simples lista suspensa ajudará a todos da equipe do projeto a entenderem melhor as responsabilidades.  

Razão

Esse campo de texto é utilizado para rastrear a origem do caso de uso solicitado. Os requisitos existem para razões específicas. Esse campo registra uma explicação ou uma referência a uma explicação. Por exemplo, a referência pode ser a uma página ou número de linha de uma especificação de requisito do produto ou a um marcador de minutos em um vídeo de uma importante entrevista com o cliente.

Atributos para SUPP

Status
Configurado após a negociação e revisado pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da linha de base do projeto.

 
Proposto
Utilizado para descrever as especificações suplementares que estão em discussão, mas que ainda não foram revisadas e aceitas pelo "canal oficial", como um grupo de trabalho que consiste em representantes da equipe do projeto, gerenciamento do produto e comunidade de usuários ou clientes.
Aprovado
Recursos que são considerados úteis e viáveis e que foram aprovados para implementação do canal oficial.
Incorporado
Especificações suplementares incorporadas na linha de base do produto em um período específico.

Benefício

Configurado pelo Marketing, o gerente do produto ou o analista de negócios. Todos os requisitos não são criados de forma igual. Os requisitos de posição segundo seus benefícios relativos ao usuário abrem um diálogo com clientes, analistas e membros da equipe de desenvolvimento. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.
 
Crítico
Especificação essencial. A falha na implementação significa que o sistema não atenderá às necessidades do cliente. Todos os recursos críticos devem ser implementados na liberação ou o planejamento poderá falhar.
Importante
Especificações importantes para a efetividade e a eficácia do sistema para a maioria dos aplicativos. A funcionalidade não pode ser facilmente fornecida de alguma outra forma. A falta da inclusão de uma especificação importante pode afetar a satisfação do cliente ou do usuário ou mesmo a receita, mas não afeta a liberação.
Útil
As especificações que são úteis em aplicativos menos comuns serão utilizadas com menos freqüência ou para os quais podem ser alcançadas soluções alternativas razoavelmente eficientes. Nenhum impacto significativo na receita ou na satisfação do cliente pode ser esperado se esse item não estiver incluído em uma liberação.

Esforço

Configurado pela equipe de desenvolvimento. Como algumas especificações requerem mais tempo e recursos que outras, estimar o número de equipe ou semanas de pessoas, as linhas de código requeridas ou os pontos de função, por exemplo, é a melhor maneira de calibrar a complexidade e configurar as expectativas daquilo que pode ou não pode ser feito em um determinado período. Utilizado no gerenciamento do escopo e na determinação da prioridade de desenvolvimento.  

Risco

Configurado pela equipe de desenvolvimento com base na probabilidade de o projeto passar por eventos indesejáveis, como overruns de custo, atrasos no planejamento ou mesmo cancelamento. A maioria dos gerentes de projetos considera a categorização dos riscos como suficientemente alta, média ou baixa, embora outras gradações sejam possíveis. O risco geralmente pode ser avaliado indiretamente, medindo a incerteza (faixa) da estimativa de planejamento das equipes dos projetos.  

Estabilidade

Configurada pelo analista e equipe de desenvolvimento com base na probabilidade de a especificação ser alterada ou o entendimento da equipe da especificação ser alterado. Usado para ajudar a estabelecer as prioridades de desenvolvimento e a determinar os itens que deverão ser extraídos. 

Liberação de Destino

Registra a versão do produto desejada na qual o atributo especificado ou o recurso aparecerá primeiro. Esse campo pode ser utilizado para alocar as especificações em uma determinada liberação da linha de base. Quando combinado ao campo de status, a sua equipe pode propor, registrar e discutir diversas especificações da liberação sem confirmá-las no desenvolvimento. Serão implementadas apenas as especificações cujo Status é configurado como Incorporado e cuja Liberação de Destino é definida. Quando ocorrer o gerenciamento do escopo, o Número da Versão da Liberação de Destino pode ser aumentado para que o item permaneça no documento de especificação suplementar, mas será planejado por uma liberação posterior.  

Designado Para

Em vários projetos, os atributos especificados ou recursos serão designados às equipes responsáveis pela extração adicional, gravando os requisitos de software e a implementação. Essa simples lista suspensa ajudará a todos da equipe do projeto a entenderem melhor as responsabilidades.

3.4 Relatórios e Medidas

Consulte o Plano de Medida do SPEU.

3.5 Gerenciamento de Mudanças de Requisitos

Consulte o Plano de Gerenciamento de Configuração do SPEU.
Os seguintes grupos de acesso serão configurados para controlar o acesso aos requisitos no Rational RequisitePro.

 
 

- Administrador da Ferramenta - possui acesso completo a cada parte da ferramenta.   Pode incluir e remover pessoas, alterar seus direitos de acesso, etc. 

- Autor - pode criar novos requisitos 

- Gerente de Projetos - configura o status dos requisitos 

- Tester_QA - configura o status dos requisitos dos casos de teste.

3.6       Fluxos de Trabalho e Atividades

Consulte o Caso de Desenvolvimento do SPEU.

4. Marcos

Consulte o Plano de Desenvolvimento de Software do SPEU.

5. Treinamento e Recursos

Consulte o Plano de Desenvolvimento de Software do SPEU.

 
 
Rational Unified Process