Diretrizes: Plano de Gerenciamento de

Requisitos
Tópicos

• Relacionamento com Outros Planos

• Organização, Responsabilidade e Interfaces
• Identificação de Itens de Rastreabilidade
• Especificação de Rastreabilidade
• Atributos de Exemplo
• Seleção de Atributos
• Relatórios e Medidas
• Gerenciamento de Mudanças de Requisitos

Relacionamento com Outros Planos

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.

Organização, Responsabilidades e Interfaces

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?
Identificação de Itens de Rastreabilidade

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.

Especificação de Rastreabilidade

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.

Atributos de Exemplo

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
Seleção de Atributos

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.

Relatórios e Medidas

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 Usado Para

Relatórios/Métricas

Prioridade de Pode ser uma única lista

Desenvolvimento de Casos de classificada por uma combinação
Uso (lista de Casos de Uso ponderada desses atributos ou
classificados por Risco, listas classificadas
Benefício, Esforço, separadamente. Usadas para
Estabilidade e Impacto na Atividade: Priorizar Casos de
Arquitetura). Uso.
Porcentagem de Controlar o andamento durante a
Características em cada definição da baseline do projeto.
Categoria de Status.
- classificada pelo Release-alvo- controlar o andamento por
release
- ponderada pelo Esforço - fornecer uma métrica de
andamento mais precisa.
Características classificadas - identificar as características de
por Risco risco. Útil para gerenciar o
escopo e para atribuir
características a iterações.
- classificadas pelo Release- - avaliar se as características de
alvo, com Risco de risco foram programadas cedo ou
Desenvolvimento somado para tarde no projeto.
cada Release-alvo
Seções de Casos de Uso - decidir quais seções de casos de
classificadas por Estabilidade uso precisam ser estabilizadas.
- ponderadas ou classificadas - priorizar os casos de uso
pelas Influências da Arquitetura significativos do ponto de vista
da arquitetura e/ou de grande
esforço que devem ser
estabilizados primeiro.
Requisitos com Atributos Quando os requisitos são
Indefinidos 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 Um relatório de links de
links de rastreabilidade rastreabilidade incorretos ou
incompletos incompletos é usado para Pontos
de Verificação: Especificação
dos Requisitos de Software.

Outros relatórios:

• Relatório: Caso de Uso

• Relatório: Relatório Sintético de Modelo de Casos de Uso
• Relatório: Encenação de Caso de Uso
• Relatório: Ator
• Relatório: Classe

Consulte Visão Geral de Relatórios para obter mais detalhes.

Gerenciamento de Mudanças de Requisitos

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

O que é o Gerenciamento de Requisitos?

Segundo RUP, Gerenciamento de requisitos é uma abordagem sistemática para

localizar, documentar, organizar e controlar os requisitos variáveis em um sistema.

Para um bom gerenciamento é necessário que os requisitos identificados sejam de forma

clara, junto com os atributos aplicáveis e a rastreabilidade para outros requisitos e
outros artefatos do projeto.

A coleta de requisitos pode parecer uma tarefa bem precisa. Na realidade, porém, os
projetos enfrentam dificuldades pelos seguintes motivos:
 • Nem sempre os requisitos são óbvios e podem vir de várias fontes.
• Os requisitos nem sempre são expressos em palavras de modo fácil ou claro.
• Existem diversos tipos de requisitos em diferentes níveis de detalhe.
• O número de requisitos pode se tornar impossível de gerenciar se eles não forem
controlados.
• Os requisitos estão relacionados uns com os outros, e também com o produto
liberado do processo de engenharia do software.
• Os requisitos têm propriedades exclusivas ou valores de propriedade. Por
exemplo, eles não são necessariamente igualmente importantes ou igualmente fáceis
de se atender.
• Há várias partes interessadas, o que significa que os requisitos precisam ser
gerenciados por grupos de pessoas de diferentes funções.
• Os requisitos são alterados.

Então, que habilidades você precisa desenvolver em sua organização para ajudá-lo a
gerenciar essas dificuldades? Aprendemos que as seguintes habilidades são importantes
para o gerenciamento:

• Análise do problema
• Noções básicas sobre as necessidades dos envolvidos
• Definição do sistema
• Gerenciamento do escopo do projeto
• Refinamento da definição do sistema
• Gerenciamento dos requisitos variáveis

Análise do problema

Essa análise é feita para o entendimento dos problemas e das necessidades iniciais dos
envolvidos e para que sejam propostas soluções de alto nível. É um ato de raciocínio e
de análise para localizar "o problema por trás do problema". Durante a análise, são
estabelecidos os problemas reais e quem são os envolvidos. Do ponto de vista negócios,
você também define as fronteiras da solução e as restrições de negócios dessa solução.
O caso de negócio do projeto também precisa ser analisado, para que haja um bom
entendimento do retorno esperado sobre o investimento feito no sistema que está sendo
criado.

Consulte o Detalhamento do Fluxo de Trabalho: Analisar o Problema na disciplina

Requisitos para obter mais informações sobre este tópico.

Noções básicas sobre as necessidades dos envolvidos

Os requisitos chegam de várias fontes; por exemplo, clientes, parceiros, usuários e

especialistas em domínios. Você precisa saber determinar quais deveriam ser as
melhores fontes, como acessá-las e como levantar informações nelas de modo eficaz. Os
indivíduos que fornecem as principais fontes dessas informações são denominados
envolvidos no projeto.

Se você estiver desenvolvendo um sistema de informações que será usado internamente

em sua empresa, poderá incluir pessoas com experiência de usuário e especialização em
domínios na equipe de desenvolvimento. Muito freqüentemente, você iniciará as
discussões no nível de modelo de negócios e não no nível de sistema. Se estiver
desenvolvendo um produto que será vendido para um mercado específico, você poderá
usar amplamente a equipe de marketing para entender melhor as necessidades dos
clientes naquele mercado.

O levantamento de informações pode ocorrer através de técnicas como entrevistas,

discussão de idéias, protótipos conceituais, questionários e análise competitiva. O
resultado é uma lista de solicitações ou de necessidades descritas em forma de texto e de
gráficos e que recebem uma prioridade entre si.

Consulte o Detalhamento do Fluxo de Trabalho: Entender as Necessidades dos

Envolvidos para obter mais detalhes sobre este tópico.

Definição do sistema

Definir o sistema significa converter e organizar o entendimento das necessidades dos

envolvidos em uma descrição significativa do sistema a ser criado. No início da
definição do sistema, são tomadas decisões sobre o que constitui um requisito, o
formato da documentação, a formalidade da linguagem, o grau de especificação dos
requisitos (quantos e com qual detalhamento), a prioridade das solicitações e o esforço
estimado (duas avaliações muito diferentes, geralmente determinadas por pessoas
distintas em exercícios separados), os riscos técnicos e de gerenciamento e o escopo
inicial. Parte dessa atividade pode incluir modelos de design e protótipos iniciais
diretamente relacionados aos mais importantes requisitos dos envolvidos. O resultado
da definição é uma descrição do sistema que usa as representações em linguagem
natural e gráfica.

Consulte o Detalhamento do Fluxo de Trabalho: Definir o Sistema na disciplina

Requisitos para obter mais detalhes sobre este tópico.

Gerenciamento do escopo do projeto

Para executar um projeto de modo eficiente, é necessário priorizar cuidadosamente os

requisitos com base nas informações recebidas de todos os envolvidos e gerenciar esse
escopo. Muitos projetos são prejudicados devido a desenvolvedores ocupados em criar
os chamados "Ovos de páscoa" (características que o desenvolvedor acha interessantes e
desafiadoras), em vez de se concentrar desde o início em tarefas que diminuem um risco
de projeto ou estabilizam a arquitetura da aplicação. Certifique-se de resolver ou
diminuir os riscos em um projeto o mais cedo possível, desenvolvendo o sistema
gradativamente e escolhendo cuidadosamente os requisitos para cada incremento que
diminui os riscos conhecidos. Isso significa que você precisa negociar o escopo de cada
iteração com os envolvidos no projeto. Geralmente, isso exige uma boa capacidade de
gerenciamento das expectativas da saída do projeto em suas diferentes fases. Também é
necessário controlar as fontes dos requisitos, a aparência dos produtos liberados do
projeto e o próprio processo de desenvolvimento.

Consulte o Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema na

disciplina Requisitos para obter informações adicionais sobre este tópico.
Refinamento da definição do sistema

A definição detalhada do sistema precisa ser apresentada de maneira que os envolvidos

possam entendê-la, concordar com ela e sair dela. Ela precisa abordar não apenas a
funcionalidade, mas também a compatibilidade com os requisitos legais ou reguladores,
a usabilidade, a confiabilidade, o desempenho, a capacidade de suporte e de
manutenção. Um erro freqüente é acreditar que o que você sente que é difícil criar
precisa ter uma definição complexa. Isso cria dificuldades para explicar a finalidade do
projeto e do sistema. As pessoas podem ficar impressionadas, mas não darão boas
contribuições porque não entendem. É necessário dar mais atenção ao entendimento do
público para o qual os artefatos estão sendo produzidos; geralmente, são necessários
diferentes tipos de descrição para públicos distintos.

Vimos que a metodologia de casos de uso, geralmente em combinação com protótipos

visuais simples, é uma maneira muito eficiente de comunicar a finalidade e de definir os
detalhes do sistema. Os casos de uso ajudam a inserir os requisitos em um contexto; eles
ilustram o modo como o sistema será usado.

Outro componente da definição detalhada do sistema é estabelecer como o sistema

deverá ser testado. Os planos de teste e as definições dos testes a serem executados
indicam os recursos do sistema que serão verificados.

Consulte o Detalhamento do Fluxo de Trabalho: Refinar a Definição do Sistema na

disciplina Requisitos para obter mais informações.

Gerenciamento dos requisitos variáveis

Por mais que você tenha cuidado ao definir os requisitos, sempre haverá itens que são
alterados. O que torna complexo o gerenciamento dos requisitos variáveis não é apenas
o fato de que um requisito alterado significa a necessidade de gastar tempo com a
implementação de uma nova característica específica, mas também que uma mudança
em um requisito poderá ter impacto em outros. Você precisa garantir que os requisitos
receberão uma estrutura que aceite bem as mudanças e usar links de rastreabilidade para
representar as dependências entre os requisitos e outros artefatos do ciclo de vida do
desenvolvimento. O gerenciamento de mudanças inclui atividades como: estabelecer
uma baseline, determinar as dependências importantes a serem rastreadas, estabelecer a
rastreabilidade entre itens relacionados e implementar o controle de mudanças.

Consulte o Detalhamento do Fluxo de Trabalho: Gerenciar Requisitos Variáveis na

disciplina Requisitos e o Detalhamento do Fluxo de Trabalho: Gerenciar Solicitações de
Mudança na disciplina Gerenciamento de Configuração e Mudança para obter mais
detalhes sobre este tópico.

Como o Desenvolvimento é Baseado em Casos

de Uso?
Recomendamos a utilização dos casos de uso como método para a organização dos
requisitos funcionais. Em vez de fazer uma lista de requisitos com marcadores,
organize-os de forma que ilustrem o modo como uma pessoa poderá usar o sistema. Isso
permite maior abrangência e consistência e também fornece um melhor entendimento
da importância de um requisito do ponto de vista do usuário.

A partir de um modelo de sistema tradicional orientado a objetos, geralmente é difícil

definir como um sistema faz o que se espera que ele faça. Essa dificuldade resulta da
falta de um "thread vermelho" através do sistema quando executa certas tarefas. No
Rational Unified Process (RUP), os casos de uso são essa linha, pois definem o
comportamento de um sistema. Eles não fazem parte da orientação a objetos tradicional,
mas sua importância se tornou ainda mais evidente. Isso é mais enfatizado ainda pelo
fato de que os casos de uso fazem parte da Linguagem Unificada de Modelagem.

O RUP emprega uma "abordagem baseada em casos de uso", o que significa que os
casos de uso definidos para um sistema são a base de todo o processo de
desenvolvimento.

Os casos de uso fazem parte de várias disciplinas.

• O conceito de casos de uso pode ser usado para representar processos de

negócios, conforme definido na disciplina modelagem de negócios. Essa variante de
caso de uso é denominada "caso de uso de negócios".
• O modelo de caso de uso é um dos principais artefatos resultantes da disciplina
requisitos. Os casos de uso criam um modelo para identificar o que o sistema precisa
fazer do ponto de vista do usuário. Os casos de uso constituem um conceito
fundamental importante que precisa ser aceitável para o cliente, para os
desenvolvedores e para os testadores do sistema.
• Em análise e design, os casos de uso são realizados em um modelo de design.
Você pode criar realizações de casos de uso, que descrevem como os casos de uso
são suportados pelo design no que se refere à interação de objetos no modelo de
design. Esse modelo descreve, em termos de objetos de design, as diferentes partes
do sistema que deverá ser implementado e como elas precisam interagir para
suportar os casos de uso necessários.
• Durante a implementação, o modelo de design atua como a especificação da
implementação. Como os casos de uso são a base do modelo de design, eles são
implementados em relação às classes de design de colaboração.
• Durante o teste, os casos de uso fornecem os cenários necessários que compõem
a principal base para identificação funcional de cenários de teste. Esses cenários de
teste são usados para originar casos de teste e scripts de teste; a funcionalidade do
sistema é verificada executando cenários de teste que experimentam cada caso de
uso.
• Na disciplina Gerenciamento de Projeto, os casos de uso são usados como base
para planejar o desenvolvimento iterativo.
• Na disciplina Implantação, os casos de uso formam uma base para o que está
descrito nos manuais do usuário. Eles também podem ser usados para definir as
unidades de pedido do produto. Por exemplo, um cliente pode obter um sistema
configurado com uma combinação específica de casos de uso.

Conceitos: Requisitos
Mais informações sobre este tópico podem ser encontradas em:

• Conceitos: Gerenciamento de Requisitos

• Conceitos: Tipos de Requisitos
• Conceitos: Rastreabilidade.
• Conceitos: Design Centrado no Usuário.
• Artigo: Applying Requirements Management with Use Cases

Um requisito é definido como "uma condição ou uma capacidade com a qual o sistema
deve estar de acordo".

Existem vários tipos de requisitos. Um modo de categorizá-los é descrito como o

modelo FURPS+ [GRA92], usando o acrônimo FURPS para descrever as principais
categorias de requisitos com subcategorias como é mostrado abaixo.

• Funcionalidade
• Usabilidade
• Confiabilidade
• Desempenho
• Suportabilidade

O "+" em FURPS+ é para lembrá-lo de incluir requisitos como:

• restrições de design
• requisitos de implementação
• requisitos de interface
• requisitos físicos.

(Consulte também [IEEE Std 610.12.1990].)

Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar,
sem levar em consideração restrições físicas. Geralmente, isso é melhor descrito em um
modelo de casos de uso e em casos de uso. Os requisitos funcionais especificam,
portanto, o comportamento de entrada e saída de um sistema.

Os requisitos que não são funcionais, como os listados abaixo, às vezes são chamados
de requisitos não funcionais. Vários requisitos não são funcionais e descrevem apenas
atributos do sistema ou atributos do ambiente do sistema. Embora alguns deles possam
ser capturados em casos de uso, aqueles que não puderem talvez estejam especificados
em Especificações Suplementares. Os requisitos não funcionais são aqueles que dizem
respeito a questões como as descritas abaixo.

Uma definição completa dos requisitos do software, dos casos de uso e das
Especificações Suplementares pode ser reunida para definir uma Especificação de
Requisitos de Software (SRS) para uma "característica" particular ou outros
agrupamentos de subsistemas.

Funcionalidade

Os requisitos funcionais podem incluir:

 • conjuntos de recursos
• habilidades
• segurança

Usabilidade

Os requisitos de usabilidade podem incluir subcategorias como:

• fatores humanos (consulte Conceitos: Design Centrado no Usuário)

• estética
• consistência na interface do usuário (consulte Diretrizes: Interface do Usuário)
• ajuda on-line e contextual
• assistentes e agentes
• documentação do usuário
• materiais de treinamento

Confiabilidade

Os requisitos de confiabilidade a serem considerados são:

• freqüência e gravidade de falha

• possibilidade de recuperação
• possibilidade de previsão
• exatidão
• tempo médio entre falhas (MTBF)

Desempenho

Um requisito de desempenho impõe condições aos requisitos funcionais. Por exemplo,

para uma determinada ação, ele pode especificar parâmetros de desempenho para:

• velocidade
• eficiência
• disponibilidade
• exatidão
• taxa de transferência
• tempo de resposta
• tempo de recuperação
• uso de recurso

Suportabilidade

Os requisitos de suporte podem incluir:

• possibilidade de teste
• extensibilidade/li>
• adaptabilidade
• manutenibilidade
• compatibilidade
 • possibilidade de configuração
• possibilidade de serviço
• possibilidade de instalação
• possibilidade de localização (internacionalização)

Requisito de Design

Um requisito de design, freqüentemente chamado de uma restrição de design,

especifica ou restringe o design de um sistema.

Requisito de Implementação

Um requisito de implementação especifica ou restringe o código ou a construção de um

sistema. Como exemplos, podemos citar:

• padrões obrigatórios
• linguagens de implementação
• políticas de integridade de banco de dados
• limites de recursos
• ambientes operacionais

Requisito de Interface

Um requisito de interface especifica:

• um item externo com o qual o sistema deve interagir

• restrições de formatos, tempos ou outros fatores usados por tal interação

Requisito Físico

Um requisito físico especifica uma característica física que um sistema deve possuir,
por exemplo,

• material
• forma
• tamanho
• peso

Esse tipo de requisito pode ser usado para representar requisitos de hardware, como as
configurações físicas de rede obrigatórias.