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

1.2 Escopo

Este 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

CSPS Software Development Plan

CSPS Development Case

CSPS Measurement Plan

CSPS Configuration Management Plan

2. Gerenciamento de Requisitos

2.1 Organização, Responsabilidades e Interfaces

Consulte o CSPS Software Development Plan.

2.2 Ferramentas, Ambiente e Infra-estrutura

O Rational RequisitePro será usado para gerenciar requisitos. Para obter mais informações sobre a infra-estrutura e o ambiente, consulte o CSPS Software Development Plan.

3. O Programa de Gerenciamento de Requisitos

3.1 Identificação de Requisitos

Artefato (Tipo de Documento)	Tipo de Requisito	Descrição
Visão (VIS)	Necessidade dos Envolvidos (NEED)	A principal necessidade dos envolvidos ou dos usuários
Visão (VIS)	Recurso (FEAT)	Condições ou recursos desse release do sistema
Modelo de Casos de Uso	Caso de Uso (UC)	Os casos de uso deste release, documentados no Rational Rose, com detalhes no Rational RequisitePro.
Especificação Suplementar (SS)	Requisito Suplementar (SUPP)	Os requisitos não-funcionais que não são capturados no modelo de casos de uso

Tabela 3.1?1 Artefatos e Tipos de Requisito

3.2 Rastreabilidade

Figura -1 - Diagrama de rastreabilidade

Critérios de FEAT

As características serão rastreadas em casos de uso.

Critérios de NEED

As necessidades do usuário serão rastreadas nas características (FEAT). Quaisquer necessidades não rastreadas em uma FEAT não serão implementadas.

Critérios de UC

Os casos de uso serão rastreados nos casos de teste.

Critérios de SUPP

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

3.3 Atributos

Atributos de FEAT

Status

Definido após a negociação e a revisão feita pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da baseline do projeto.

Proposto	Usado para descrever as características que estão em discussão, mas que ainda não foram revisadas nem aceitas pelo "canal oficial" como, por exemplo, um grupo de trabalho formado pelos representantes da equipe do projeto, a gerência do produto e a comunidade de usuários ou clientes.
Aprovado	Recursos considerados úteis e viáveis e que foram aprovados para serem implementados pelo canal oficial.
Incorporado	Características incorporadas à baseline do produto em um momento específico.

Benefício

Definido pelo Marketing, gerente de produto ou analista de negócio. Todos os requisitos diferem entre si. A ordenação de requisitos por benefício relativo ao usuário final abre uma caixa de diálogo que mostra os clientes, os analistas e os membros da equipe de desenvolvimento. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Crítico

Características essenciais. A não implementação implica que o sistema não atenderá às necessidades do cliente. Todas as características críticas devem ser implementadas no release. Do contrário, a programação apresentará falha.

Importante

As características importantes à eficácia do sistema para a maioria dos aplicativos. A funcionalidade não poderá ser fornecida facilmente de outra maneira. A não inclusão de uma característica importante poderá afetar a satisfação do cliente ou do usuário, ou até mesmo a receita, mas o release não será atrasado devido à não inclusão de qualquer característica importante.

Útil

As características úteis em aplicativos menos comuns (que serão usadas com menos freqüência) ou para as quais artifícios razoavelmente eficazes podem ser obtidos. Não se espera nenhum impacto significativo sobre a receita ou a satisfação do cliente se este item não for incluído em um release.

Esforço

Definido pela equipe de desenvolvimento. Como algumas funcionalidades necessitam de mais tempo e de mais recursos do que outras, estimar o número de semanas de participação de cada pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é a melhor maneira de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado período de tempo. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Risco

Definido pela equipe de desenvolvimento com base na probabilidade de ocorrerem eventos indesejados no projeto, como excesso de custos, atrasos nas programações ou, até mesmo, cancelamentos. A maioria dos gerentes de projeto acredita que categorizar os riscos como alto, médio e baixo é suficiente, embora sejam possíveis gradações mais refinadas. Os riscos podem geralmente ser avaliados indiretamente, através da medição da inconstância (faixa) da estimativa de programação das equipes de projeto.

Estabilidade

Definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de a característica mudar ou na compreensão da equipe em relação a essa mudança. Usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para os quais a inferência adicional é a próxima ação apropriada.

Release-alvo

Registra a versão de produto em que a característica aparecerá primeiro. Este campo pode ser usado para alocar características de um documento de visão em um release de baseline específico. Quando ele estiver combinado ao campo de status, a equipe poderá propor, registrar e discutir várias características do release sem envolvê-las no desenvolvimento. Somente serão implementados os recursos cujo Status estiver definido como Incorporado e cujo Release-alvo estiver definido. Quando ocorre um gerenciamento de escopo, o Número da Versão do Release-Alvo pode ser aumentado, a fim de que o item permaneça no documento de visão, mas seja programado para um release posterior.

Atribuído A

Em vários projetos, as características serão atribuídas às "equipes de característica" responsáveis pela inferência posterior, gravação dos requisitos de software e implementação. Esta simples lista suspensa ajudará todos os membros da equipe do projeto a compreender melhor as responsabilidades.

Motivo

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

Atributos de NEED

Status

Definido após a negociação e a revisão feita pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da baseline do projeto.

Proposto	Usado para descrever as necessidades que estão em discussão, mas que ainda não foram revisadas nem aceitas pelo "canal oficial" como, por exemplo, um grupo de trabalho formado pelos representantes da equipe do projeto, a gerência do produto e a comunidade de usuários ou clientes.
Aprovado	Recursos considerados úteis e viáveis e que foram aprovados para serem implementados pelo canal oficial.
Incorporado	Necessidades que estão sendo atendidas pela baseline do produto em um momento específico.

Esforço

Definido pela equipe de desenvolvimento. Como algumas necessidades requerem mais tempo e recursos que outras, estimar o número de semanas de participação de cada pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é a melhor maneira de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado período de tempo. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Risco

Estabilidade

Definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de a necessidade mudar ou na compreensão da equipe em relação a essa mudança. Usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para os quais a inferência adicional é a próxima ação apropriada.

Release-alvo

Registra a versão de produto em que a necessidade será atendida primeiro. Este campo pode ser usado para alocar características de um documento de visão em um release de baseline específico. Quando ele estiver combinado ao campo de status, a equipe poderá propor, registrar e discutir várias características do release sem envolvê-las no desenvolvimento. Somente serão atendidas as necessidades cujo Status estiver definido como Incorporado e cujo Release-alvo estiver definido. Quando ocorre um gerenciamento de escopo, o Número da Versão do Release-Alvo pode ser aumentado, a fim de que o item permaneça no documento de visão, mas seja programado para um release posterior.

Motivo

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

Atributos de UC

Status

Definido após a negociação e a revisão feita pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da baseline do projeto.

Proposto	Usado para descrever os casos de uso que estão em discussão, mas que ainda não foram revisados nem aceitos pelo "canal oficial" como, por exemplo, um grupo de trabalho formado pelos representantes da equipe do projeto, a gerência do produto e a comunidade de usuários ou clientes.
Aprovado	Os casos de uso considerados úteis e viáveis e que foram aprovados para serem implementados pelo canal oficial.
Incorporado	Casos de uso incorporados à baseline do produto em um momento específico.

Benefício

Definido pelo Marketing, gerente de produto ou analista de negócio. Todos os requisitos diferem entre si. A ordenação de casos de uso por benefício relativo ao usuário final abre uma caixa de diálogo que mostra os clientes, os analistas e os membros da equipe de desenvolvimento. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Crítico

Casos de uso essenciais. A não implementação implica que o sistema não atenderá às necessidades do cliente. Todas os casos de uso críticos devem ser implementadas no release. Do contrário, a programação apresentará falha.

Importante

Os casos de uso importantes à eficácia do sistema para a maioria dos aplicativos. A funcionalidade não poderá ser fornecida facilmente de outra maneira. A não inclusão de uma característica importante poderá afetar a satisfação do cliente ou do usuário, ou até mesmo a receita, mas o release não será atrasado devido à não inclusão de qualquer característica importante.

Útil

Os casos de uso úteis em aplicativos menos comuns (que serão usados com menos freqüência) ou para os quais artifícios razoavelmente eficazes podem ser obtidos. Não se espera nenhum impacto significativo sobre a receita ou a satisfação do cliente se este item não for incluído em um release.

Esforço

Definido pela equipe de desenvolvimento. Como alguns casos de uso necessitam de mais tempo e de mais recursos que outros, estimar o número de semanas de participação de cada pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é a melhor maneira de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado período de tempo. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Risco

Estabilidade

Definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de o caso de uso mudar ou na compreensão da equipe em relação a essa mudança. Usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para os quais a inferência adicional é a próxima ação apropriada.

Release-alvo

Registra a versão de produto em que o caso de uso aparecerá primeiro. Este campo pode ser usado para alocar casos de uso de um relatório sintético de caso de uso em um release de baseline específico. Quando ele estiver combinado ao campo de status, a equipe poderá propor, registrar e discutir vários casos de uso do release sem envolvê-los no desenvolvimento. Somente serão implementados os recursos cujo Status estiver definido como Incorporado e cujo Release-alvo estiver definido. Quando ocorre um gerenciamento de escopo, o Número da Versão do Release-Alvo pode ser aumentado, a fim de que o item permaneça no documento de visão, mas seja programado para um release posterior.

Atribuído A

Em vários projetos, os casos de uso serão atribuídos às equipes responsáveis pela inferência posterior, gravação dos requisitos de software e implementação. Esta simples lista suspensa ajudará todos os membros da equipe do projeto a compreender melhor as responsabilidades.

Motivo

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

Atributos de SUPP

Status

Definido após a negociação e a revisão feita pela equipe de gerenciamento do projeto. Controla o andamento durante a definição da baseline do projeto.

Proposto	Usado para descrever as especificações suplementares que estão em discussão, mas que ainda não foram revisadas nem aceitas pelo "canal oficial" como, por exemplo, um grupo de trabalho formado pelos representantes da equipe do projeto, a gerência do produto e a comunidade de usuários ou clientes.
Aprovado	Recursos considerados úteis e viáveis e que foram aprovados para serem implementados pelo canal oficial.
Incorporado	Especificações complementares incorporadas à baseline do produto em um momento específico.

Benefício

Definido pelo Marketing, gerente de produto ou analista de negócio. Todos os requisitos diferem entre si. A ordenação de requisitos por benefício relativo ao usuário final abre uma caixa de diálogo que mostra os clientes, os analistas e os membros da equipe de desenvolvimento. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Crítico

Especificação essencial. A não implementação implica que o sistema não atenderá às necessidades do cliente. Todas as características críticas devem ser implementadas no release. Do contrário, a programação apresentará falha.

Importante

As especificações importantes à eficácia do sistema para a maioria dos aplicativos. A funcionalidade não poderá ser fornecida facilmente de outra maneira. A não inclusão de uma especificação importante poderá afetar a satisfação do cliente ou do usuário, ou até mesmo a receita, mas o release não será atrasado devido à não inclusão de qualquer característica importante.

Útil

As especificações úteis em aplicativos menos comuns (que serão usadas com menos freqüência) ou para as quais artifícios razoavelmente eficazes podem ser obtidos. Não se espera nenhum impacto significativo sobre a receita ou a satisfação do cliente se este item não for incluído em um release.

Esforço

Definido pela equipe de desenvolvimento. Como algumas especificações necessitam de mais tempo e de mais recursos que outras, estimar o número de semanas de participação de cada pessoa ou equipe, as linhas de código necessárias ou os pontos de função, por exemplo, é a melhor maneira de avaliar a complexidade e definir expectativas do que poderá ou não ser feito em um determinado período de tempo. Usado para gerenciar o escopo e determinar a prioridade do desenvolvimento.

Risco

Estabilidade

Definido pelo analista e pela equipe de desenvolvimento com base na probabilidade de as especificação mudar ou na compreensão da equipe em relação a essa mudança. Usado para ajudar a estabelecer prioridades de desenvolvimento e determinar os itens para os quais a inferência adicional é a próxima ação apropriada.

Release-alvo

Registra a versão de produto em que a característica ou o atributo especificado aparecerá primeiro. Este campo pode ser usado para alocar especificações em um release de baseline específico. Quando ele estiver combinado ao campo de status, a equipe poderá propor, registrar e discutir várias especificações do release sem envolvê-las no desenvolvimento. Somente serão implementados as especificações cujo Status estiver definido como Incorporado e cujo Release-alvo estiver definido. Quando ocorre um gerenciamento de escopo, o Número da Versão do Release-Alvo pode ser aumentado, a fim de que o item permaneça no documento de especificação, mas seja programado para um release posterior.

Atribuído A

Em vários projetos, as características ou os atributos específicos serão designados às equipes responsáveis pela inferência posterior, gravação dos requisitos de software e implementação. Esta simples lista suspensa ajudará todos os membros da equipe do projeto a compreender melhor as responsabilidades.

3.4 Relatórios e Métricas

Consulte o CSPS Measurement Plan.

3.5 Gerenciamento de Mudança de Requisitos

Consulte o CSPS Configuration Management Plan.

Os grupos de acesso a seguir serão configurados para controlar o acesso aos requisitos no Rational RequisitePro.

·Administrador de Ferramenta - tem total acesso a todas as partes da ferramenta. Pode adicionar e remover pessoas, mudar seus direitos de acesso etc.

·Autor - pode criar novos requisitos

·Gerente de Projeto - define o status dos requisitos

·Tester_QA - define o status dos requisitos de caso de teste.

3.6 Fluxos de Trabalho e Atividades

Consulte o CSPS Development Case.

4. Marcos

Consulte o CSPS Software Development Plan.

5. Treinamento e Recursos

Consulte o CSPS Software Development Plan.