Clique aqui para ver os conceitos relativos a Requisitos. Clique aqui para obter uma visão geral do fluxo de trabalho da disciplina Requisitos. Clique aqui para obter uma visão geral sobre as atividades de Requisitos. Clique aqui para ver os artefatos usados em Requisitos. Clique aqui para ver as diretrizes relacionadas a Requisitos.

Conceitos

Finalidade Início da página

A finalidade da disciplina Requisitos é:

  • Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o sistema deve fazer.
  • Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema.
  • Definir as fronteiras do sistema (ou delimitar o sistema).
  • Fornecer uma base para planejar o conteúdo técnico das iterações.
  • Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema.
  • Definir uma interface de usuário para o sistema, focando nas necessidades e metas dos usuários.

Para atingir essas metas, é importante, antes de tudo, compreender a definição e o escopo do problema que tentamos resolver com este sistema.  As Regras de Negócios, o Modelo de Casos de Uso de Negócios e o Modelo de Objetos de Negócios desenvolvidos durante a Modelagem do Negócio servirão como informações importantes nesse trabalho.  Os envolvidos são identificados e as Solicitações dos Principais Envolvidos são recolhidas, reunidas e analisadas. 

Um documento de visão, um modelo de casos de uso, casos de uso e a Especificação Suplementar são desenvolvidos para descrever integralmente o sistema -  o que o sistema fará - em um trabalho em que todos os envolvidos, incluindo clientes e usuários potenciais, são vistos como fontes de informações (além dos requisitos do sistema).

As Solicitações dos Principais Envolvidos são recolhidas e reunidas a partir de fontes existentes para obter uma "lista de desejos" do que as diversas pessoas envolvidas no projeto (clientes, usuários, defensores do produto) esperam e desejam que o sistema contenha, juntamente com informações de como cada solicitação foi considerada pelo projeto.

O documento de visão fornece uma visão completa do sistema de software em desenvolvimento e serve de suporte ao contrato entre a autoridade dos fundos e a organização de desenvolvimento.  Todo projeto precisa de uma fonte para capturar as expectativas entre os envolvidos.  O documento de visão é escrito com base na perspectiva dos clientes, focalizando as características essenciais do sistema e os níveis aceitáveis de qualidade.  A Visão deve incluir uma descrição de quais características serão incluídas, bem como aquelas que foram consideradas, mas não incluídas.  Ela também deve especificar as capacidades operacionais (volumes, tempos de resposta, precisões), os perfis dos usuários (quem usará o sistema) e as interfaces interoperacionais com entidades externas ao sistema, quando for o caso. O documento de visão fornece uma base contratual para os requisitos visíveis dos envolvidos.

O modelo de casos de uso deve servir como um meio de comunicação e pode servir como um contrato entre o cliente, os usuários e os desenvolvedores do sistema sobre a funcionalidade do sistema, que permite:

  • que clientes e usuários validem que o sistema ficará como eles esperava.
  • que os desenvolvedores do sistema construam o que é esperado.

O modelo de casos de uso consiste em casos de uso e atores. Cada caso de uso do modelo é descrito detalhadamente, mostrando passo a passo como o sistema interage com os atores, e o que o sistema faz no caso de uso. Os casos de uso funcionam como um thread unificador no decorrer do ciclo de vida do software; o mesmo modelo de casos de uso é utilizado nas atividades de análise, design, implementação e teste do sistema.

As Especificações Suplementares são um complemento importante para o modelo de casos de uso, porque juntos eles capturam todos os requisitos do software (funcionais e não funcionais) que precisam ser descritos para servir como uma especificação de requisitos de software completa.

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

Um Plano de Gerenciamento de Requisitos especifica as informações e controla os mecanismos que serão coletados e usados para medir, relatar e controlar mudanças nos requisitos do produto. 

Para complementar os artefatos mencionados acima, também foram desenvolvidos os artefatos a seguir:

O Glossário é importante porque define uma terminologia comum que é usada de forma consistente no projeto ou na organização. 

A Encenação de Caso de Uso e o Protótipo da Interface do Usuário resultam da elaboração de modelo e protótipo de interface de usuário, feitos paralelamente a outras atividades dos requisitos.  Esses artefatos fornecem importantes mecanismos de feedback nas iterações posteriores para descobrir requisitos desconhecidos ou não específicos.

Relação com Outras Disciplinas Início da página

A disciplina Requisitos está relacionada a outras disciplinas do processo.



Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process