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 Relatórios/Métricas

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

Pode ser uma única lista classificada por uma combinação ponderada desses atributos ou listas classificadas separadamente.  Usadas para Atividade: Priorizar Casos de Uso.

Porcentagem de Características em cada Categoria de Status.

Controlar o andamento durante a definição da baseline do projeto.

 - classificada pelo Release-alvo

- controlar o andamento por release

 - ponderada pelo Esforço  - fornecer uma métrica de andamento mais precisa.

Características classificadas por Risco

 - identificar as características de risco.  Útil para gerenciar o escopo e para atribuir características a iterações.

 - classificadas pelo Release-alvo, com Risco de Desenvolvimento somado para cada Release-alvo

- avaliar se as características de risco foram programadas cedo ou tarde no projeto.

Seções de Casos de Uso classificadas por Estabilidade

- decidir quais seções de casos de uso precisam ser estabilizadas.

- ponderadas ou classificadas pelas Influências da Arquitetura

- 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 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 links de rastreabilidade incompletos

Um relatório de links de rastreabilidade incorretos ou 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.

F uncionalidade U sabilidade C onfiabilidade D esempenho S uportabilidade

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.