Gerência de Requisitos
Disciplina Engenharia de Software
Mauricio Volkweis Astiazara
Mirela Ferreira César
Porto Alegre, maio de 2010
Sumário
Evolução dos Requisitos
Conceito de Gerência de Requisitos
Gerenciamento de Mudanças de Requisitos
Rastreabilidade de Requisitos
Planejamento da Gerência de Requisitos
Ferramentas para Gerência de Requisitos
Conclusão
Evolução dos Requisitos
Requisitos costumam sofrer modificações porque o problema
para o qual se refere o requisito não foi inteiramente definido,
os requisitos do sistema são necessariamente incompletos.
Evolução dos Requisitos
Por que os requisitos mudam?
● Porque durante o processo de software o entendimento dos
desenvolvedores vai se modificando.
● No aperfeiçoamento de um sistema antigo ou automatização de um
processo manual podem surgir novos requisitos.
● Quando os usuários se familiarizam com o sistema, novos
requisitos surgem pelas seguintes razões:
○ A comunidade de usuários é diversificada;
○ O pessoal que paga por um sistema e os usuários desse
sistema raramente são as mesmas pessoas e;
○ A empresa e o ambiente técnico do sistema se modificam, e isso
tem de ser refletido no próprio sistema.
Evolução dos Requisitos
Evolução dos Requisitos. Adaptado de SOMMERVILLE, 2003.
Compreensão
inicial do problema
Compreensão
modificada do
problema
Requisitos
Iniciais
Requisitos
Modificados
Evolução dos Requisitos
Na perspectiva de evolução, os requisitos podem ser
classificados como:
●Voláteis
●Permanentes
Conceito
Gerência de Requisitos é o
processo de compreender e
controlar as mudanças nos
requisitos de sistemas.
Gerenciamento de Mudanças de
Requisitos
Alteração no sistema e depois nos requisitos faz com que
especificação e implementação se desajustem.
Se este tipo de situação acontecer, os requisitos cairão em
descrédito e serão relegados a segundo plano.
Deve ser adotado um processo de gerenciamento de
mudanças.
Gerenciamento de Mudanças de
Requisitos
A vantagem de utilizar um processo formal para o
gerenciamento de mudanças é que todas as propostas de
mudança são tratadas de modo consistente e que as
mudanças no documento de requisitos são feitas de maneira
controlada (SOMMERVILLE, 2003).
Gerenciamento de Mudanças de
Requisitos
Há três estágios:
1. Análise do problema e especificação da mudança.
2. Análise e custo da mudança.
3. Implementação de mudanças.
Gerenciamento de Mudanças de
Requisitos
Problema
identificado Análise do problema e
especificação da mudança
Análise e custo da mudança
Implementação de
mudanças
Requisitos e
outros artefatos
revisados
Gerenciamento de Mudanças de
Requisitos
Um dos principais problemas de um projeto é gerenciar o
escopo. Facilmente a correta gerência de escopo é perdida.
O escopo deve ser modificado com a anuência de todos os
envolvidos.
Os requisitos macro representam diretamente um eventual
aumento de escopo. Os requisitos macro que implicam novos
casos de uso devem ser inseridos somente se aprovados pelo
financiador do projeto (MAGELA, 2006).
Gerenciamento de Mudanças de
Requisitos
Requisitos podem ser alterados, incluídos ou excluídos.
Mas deve ser realizado um gerenciamento de versões,
mantendo o histórico de cada atualização, com dados como
data, projeto, usuário solicitante e motivo.
Realizar esta tarefa sem uso de ferramentas é bastante
trabalhoso (MAGELA, 2006).
Rastreabilidade de Requisitos
A facilidade de rastreamento é uma propriedade geral de uma
especificação de requisitos que reflete a facilidade de se
encontrar requisitos relacionados.
Os requisitos devem obrigatoriamente possuir rastreabilidade
para trás (origem) e para frente (projeto) para garantir a
qualidade e consistência da especificação.
Rastreabilidade de Requisitos
●A rastreabilidade apoia a gerência de mudanças.
●Quando são propostas modificações, é preciso verificar o
impacto dessas mudanças sobre outros requisitos e o
projeto do sistema.
●As informações sobre facilidade de rastreamento são,
frequentemente representadas com o uso de matrizes de
facilidade de rastreamento
Matriz de Rastreabilidade
Rastreabilidade de Requisitos
ID do
Requisito
1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 U R
1.2 U R U
1.3 R R
2.1 R U U
2.2 U
2.3 R U
3.1 R
3.2 R
A dependência entre os
requisitos é registrada na
interseção da linha com
a coluna.
Neste exemplo, "U"
indica que o requisito da
linha utiliza recursos
especificados no
requisito da coluna, e "R"
para indicar um
relacionamento fraco
entre os requisitos.
Rastreabilidade de Requisitos
Requisito
Funcional
Caso
de Uso
UC-1 UC-2 UC-3 UC-4
RF-1 <--
RF-2 <--
RF-3 <--
RF-4 <--
RF-5 <-- <--
RF-6 <--
A intersecção entre dois
componentes indica uma conexão.
É possível utilizar um símbolo na
célula para indicar o
sentido "rastreado-para" e
"rastreado-de", ou alguma outra
relação.
Matriz de Rastreabilidade
Algumas ferramentas indicam de forma automática uma relação
"suspeita" sempre que um objeto da conexão é modificado. O
"suspeito" facilita a análise de impacto numa mudança de requisitos.
Rastreabilidade de Requisitos
Requisito
do
Usuário
Requisito Funcional Elemento do
Sistema
Código Caso de
Teste
UC-28 catalog.query.sort Classe catalog catalog.sort() search.7
search.8
UC-29 catalog.query.import Classe catalog catalog.import()
catalog.validate()
search.12
search.13
search.14
A rastreabilidade pode ter relações do tipo: um-para-um,
um-para-muitos, ou muitos-para-muitos
Matriz de Rastreabilidade
Rastreabilidade de Requisitos
Tipo de Objeto Fonte da
Ligação
Tipo de Objeto Alvo da
Ligação
Fonte da Informação
Requisito de Sistema Requisito de Software Engenheiro de Sistema
Caso de Uso Requisito Funcional Analista de Requisitos
Requisito Funcional Requisito Funcional Analista de Requisitos
Requisito Funcional Caso de Teste Engenheiro de Teste
Requisito Funcional Elemento de Arquitetura de
Software
Arquiteto de Software
Requisito Funcional Outros Elementos de Projeto Projetista ou
Desenvolvedor
Elemento de Projeto Código-fonte Desenvolvedor
Regra de Negócio Requisito Funcional Analista de Requisitos
Matriz de Rastreabilidade - Prováveis fontes de conhecimento
Rastreabilidade de Requisitos
Requisitos
não-funcionais nem
sempre endereçam um
código.
Exemplo de
rastreabilidade numa
aplicação de segurança
Rastreabilidade de requisitos não-funcionais
Planejamento da Gerência de
Requisitos
Primeiro estágio da gerência de requisitos.
Deve ser decido sobre:
●Identificação dos Requisitos
●Estados dos Requisitos
●Processo de Gerenciamento de Mudanças
●Políticas de Rastreamento
●Ferramentas CASE
Planejamento da Gerência de
Requisitos
Uma vez avaliado o impacto e custo da mudança, decisões
gerencias devem ser tomadas e podem estar apoiadas em
políticas definidas no planejamento:
●Requisitos devem ser adiados?
●Será necessário alocar mais pessoas para o projeto?
●Será necessário realizar horas extras por um período?
●Será adiado o prazo de modo a acomodar os novos
requisitos?
●Será deixada, de forma consciente, menor qualidade
daquela esperada para manter o prazo?
Planejamento da Gerência de
Requisitos
●As mudanças propostas foram cuidadosamente avaliadas
por todos os envolvidos?
●As decisões sobre a incorporação dessas mudanças foram
tomadas pelas pessoas apropriadas?
●As mudanças foram comunicadas a todos os interessados?
Ferramentas para Gerência de
Requisitos
Benefícios no uso de ferramentas:
●Gerenciar versões e alterações
●Armazenar atributos dos requisitos
●Facilidade na análise de impacto
●Rastrear o status do requisito
●Controle de acesso
●Comunicação com stakeholders
●Reutilização de requisitos
Ferramentas para Gerência de
Requisitos
Esses produtos são classificados como ferramentas de
gerenciamento de requisitos e não como ferramentas de
desenvolvimento de requisitos.
Ferramentas para Gerência de
Requisitos
Estas ferramentas não substituem um processo definido que
os membros da equipe seguem para elicitar e gerenciar
requisitos.
É sugerido usar uma ferramenta quando já se tem uma
abordagem que funciona mas que requer maior eficiência pois
uma ferramenta não compensa a falta de processo, disciplina,
experiência e entendimento.
Ferramentas para Gerência de
Requisitos
Exemplos de ferramentas:
IBM Rational RequisitePro
Borland CaliberRM
HP Quality Center
Ferramentas para Gerência de
Requisitos
IBM Rational RequisitePro
Ferramentas para Gerência de
Requisitos
Borland CaliberRM
Ferramentas para Gerência de
Requisitos
HP Quality Center
Ferramentas para Gerência de
Requisitos
Sites de ferramentas:
Volere: www.volere.co.uk
INCOSE: www.incose.org
Tigris.org: www.tigris.org
Ferramentas para Gerência de
Requisitos
Volere: www.volere.co.uk
Ferramentas para Gerência de
Requisitos
INCOSE: www.incose.org
Ferramentas para Gerência de
Requisitos
Tigris.org: www.tigris.org
Conclusão
atende
Planejamento
Gerência de
Requisitos
define
Evolução dos
Requisitos
Conclusão
Evolução dos Requisitos
Melhor Compreensão do
Problema
Redefinição de Prioridades
Mudanças no Ambiente
Conclusão
Gerência de Requisitos
Gerenciamento de Mudanças
Rastreabilidade
Ferramentas CASE
apoiada por
apoiado por
Conclusão
Gerência de Requisitos
Gerenciamento de Mudanças
Rastreabilidade
Ferramentas CASE
apoiada por
apoiado por
Planejamento
Definir Processo
Definir Política
Selecionar
Referências (1 de 3)
ATLANTIC SYSTEMS GUILD LTDA. Volere Requirements
Resources: Requirements Tools. Disponível em: <http://www.
volere.co.uk/tools.htm>. Acesso em: 25/04/2010.
BLASCHEK, José Roberto. Gerência de Requisitos: O principal
problema dos projetos de software. Disponível em: <http:
//www.bfpug.com.br/islig-rio/jun-2002.htm>. Acesso em:
25/04/2010.
BORLAND. CaliberRM: enterprise software requirements
management system. Disponível em <http://www.borland.
com/us/products/caliber/index.html>. Acesso em: 28/04/2010.
Referências (2 de 3)
HEWLETT-PACKARD. HP Quality Center. Disponível em:
<https://h10078.www1.hp.
com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-
11-127-24_4000_100__>. Acesso em: 28/04/2010.
IBM. Rational RequisitePro: a requirements management tool.
Disponível em: <http://www-01.ibm.
com/software/awdtools/reqpro/>. Acesso em: 28/04/2010.
INCOSE. INCOSE Requirements Management Tools
Survey. Disponível em: <http://www.incose.
org/ProductsPubs/products/rmsurvey.aspx>. Acesso em:
27/04/2010.
Referências (3 de 3)
MAGELA, Rogério. Engenharia de Software Aplicada:
fundamentos. Rio de Janeiro: Alta Books, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São
Paulo: Pearson Addison Wesley, 2003.
TIGRIS. Software requirements management tools. Disponível
em: <http://requirements.tigris.org/>. Acesso em: 01/05/2010.
WIEGERS, Karl E. Software Requirements. 2ª ed.
Washington, USA: Microsoft Press, 2003.

Gerência de Requisitos

  • 1.
    Gerência de Requisitos DisciplinaEngenharia de Software Mauricio Volkweis Astiazara Mirela Ferreira César Porto Alegre, maio de 2010
  • 2.
    Sumário Evolução dos Requisitos Conceitode Gerência de Requisitos Gerenciamento de Mudanças de Requisitos Rastreabilidade de Requisitos Planejamento da Gerência de Requisitos Ferramentas para Gerência de Requisitos Conclusão
  • 3.
    Evolução dos Requisitos Requisitoscostumam sofrer modificações porque o problema para o qual se refere o requisito não foi inteiramente definido, os requisitos do sistema são necessariamente incompletos.
  • 4.
    Evolução dos Requisitos Porque os requisitos mudam? ● Porque durante o processo de software o entendimento dos desenvolvedores vai se modificando. ● No aperfeiçoamento de um sistema antigo ou automatização de um processo manual podem surgir novos requisitos. ● Quando os usuários se familiarizam com o sistema, novos requisitos surgem pelas seguintes razões: ○ A comunidade de usuários é diversificada; ○ O pessoal que paga por um sistema e os usuários desse sistema raramente são as mesmas pessoas e; ○ A empresa e o ambiente técnico do sistema se modificam, e isso tem de ser refletido no próprio sistema.
  • 5.
    Evolução dos Requisitos Evoluçãodos Requisitos. Adaptado de SOMMERVILLE, 2003. Compreensão inicial do problema Compreensão modificada do problema Requisitos Iniciais Requisitos Modificados
  • 6.
    Evolução dos Requisitos Naperspectiva de evolução, os requisitos podem ser classificados como: ●Voláteis ●Permanentes
  • 7.
    Conceito Gerência de Requisitosé o processo de compreender e controlar as mudanças nos requisitos de sistemas.
  • 8.
    Gerenciamento de Mudançasde Requisitos Alteração no sistema e depois nos requisitos faz com que especificação e implementação se desajustem. Se este tipo de situação acontecer, os requisitos cairão em descrédito e serão relegados a segundo plano. Deve ser adotado um processo de gerenciamento de mudanças.
  • 9.
    Gerenciamento de Mudançasde Requisitos A vantagem de utilizar um processo formal para o gerenciamento de mudanças é que todas as propostas de mudança são tratadas de modo consistente e que as mudanças no documento de requisitos são feitas de maneira controlada (SOMMERVILLE, 2003).
  • 10.
    Gerenciamento de Mudançasde Requisitos Há três estágios: 1. Análise do problema e especificação da mudança. 2. Análise e custo da mudança. 3. Implementação de mudanças.
  • 11.
    Gerenciamento de Mudançasde Requisitos Problema identificado Análise do problema e especificação da mudança Análise e custo da mudança Implementação de mudanças Requisitos e outros artefatos revisados
  • 12.
    Gerenciamento de Mudançasde Requisitos Um dos principais problemas de um projeto é gerenciar o escopo. Facilmente a correta gerência de escopo é perdida. O escopo deve ser modificado com a anuência de todos os envolvidos. Os requisitos macro representam diretamente um eventual aumento de escopo. Os requisitos macro que implicam novos casos de uso devem ser inseridos somente se aprovados pelo financiador do projeto (MAGELA, 2006).
  • 13.
    Gerenciamento de Mudançasde Requisitos Requisitos podem ser alterados, incluídos ou excluídos. Mas deve ser realizado um gerenciamento de versões, mantendo o histórico de cada atualização, com dados como data, projeto, usuário solicitante e motivo. Realizar esta tarefa sem uso de ferramentas é bastante trabalhoso (MAGELA, 2006).
  • 14.
    Rastreabilidade de Requisitos Afacilidade de rastreamento é uma propriedade geral de uma especificação de requisitos que reflete a facilidade de se encontrar requisitos relacionados. Os requisitos devem obrigatoriamente possuir rastreabilidade para trás (origem) e para frente (projeto) para garantir a qualidade e consistência da especificação.
  • 15.
    Rastreabilidade de Requisitos ●Arastreabilidade apoia a gerência de mudanças. ●Quando são propostas modificações, é preciso verificar o impacto dessas mudanças sobre outros requisitos e o projeto do sistema. ●As informações sobre facilidade de rastreamento são, frequentemente representadas com o uso de matrizes de facilidade de rastreamento
  • 16.
    Matriz de Rastreabilidade Rastreabilidadede Requisitos ID do Requisito 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 U R 1.2 U R U 1.3 R R 2.1 R U U 2.2 U 2.3 R U 3.1 R 3.2 R A dependência entre os requisitos é registrada na interseção da linha com a coluna. Neste exemplo, "U" indica que o requisito da linha utiliza recursos especificados no requisito da coluna, e "R" para indicar um relacionamento fraco entre os requisitos.
  • 17.
    Rastreabilidade de Requisitos Requisito Funcional Caso deUso UC-1 UC-2 UC-3 UC-4 RF-1 <-- RF-2 <-- RF-3 <-- RF-4 <-- RF-5 <-- <-- RF-6 <-- A intersecção entre dois componentes indica uma conexão. É possível utilizar um símbolo na célula para indicar o sentido "rastreado-para" e "rastreado-de", ou alguma outra relação. Matriz de Rastreabilidade Algumas ferramentas indicam de forma automática uma relação "suspeita" sempre que um objeto da conexão é modificado. O "suspeito" facilita a análise de impacto numa mudança de requisitos.
  • 18.
    Rastreabilidade de Requisitos Requisito do Usuário RequisitoFuncional Elemento do Sistema Código Caso de Teste UC-28 catalog.query.sort Classe catalog catalog.sort() search.7 search.8 UC-29 catalog.query.import Classe catalog catalog.import() catalog.validate() search.12 search.13 search.14 A rastreabilidade pode ter relações do tipo: um-para-um, um-para-muitos, ou muitos-para-muitos Matriz de Rastreabilidade
  • 19.
    Rastreabilidade de Requisitos Tipode Objeto Fonte da Ligação Tipo de Objeto Alvo da Ligação Fonte da Informação Requisito de Sistema Requisito de Software Engenheiro de Sistema Caso de Uso Requisito Funcional Analista de Requisitos Requisito Funcional Requisito Funcional Analista de Requisitos Requisito Funcional Caso de Teste Engenheiro de Teste Requisito Funcional Elemento de Arquitetura de Software Arquiteto de Software Requisito Funcional Outros Elementos de Projeto Projetista ou Desenvolvedor Elemento de Projeto Código-fonte Desenvolvedor Regra de Negócio Requisito Funcional Analista de Requisitos Matriz de Rastreabilidade - Prováveis fontes de conhecimento
  • 20.
    Rastreabilidade de Requisitos Requisitos não-funcionaisnem sempre endereçam um código. Exemplo de rastreabilidade numa aplicação de segurança Rastreabilidade de requisitos não-funcionais
  • 21.
    Planejamento da Gerênciade Requisitos Primeiro estágio da gerência de requisitos. Deve ser decido sobre: ●Identificação dos Requisitos ●Estados dos Requisitos ●Processo de Gerenciamento de Mudanças ●Políticas de Rastreamento ●Ferramentas CASE
  • 22.
    Planejamento da Gerênciade Requisitos Uma vez avaliado o impacto e custo da mudança, decisões gerencias devem ser tomadas e podem estar apoiadas em políticas definidas no planejamento: ●Requisitos devem ser adiados? ●Será necessário alocar mais pessoas para o projeto? ●Será necessário realizar horas extras por um período? ●Será adiado o prazo de modo a acomodar os novos requisitos? ●Será deixada, de forma consciente, menor qualidade daquela esperada para manter o prazo?
  • 23.
    Planejamento da Gerênciade Requisitos ●As mudanças propostas foram cuidadosamente avaliadas por todos os envolvidos? ●As decisões sobre a incorporação dessas mudanças foram tomadas pelas pessoas apropriadas? ●As mudanças foram comunicadas a todos os interessados?
  • 24.
    Ferramentas para Gerênciade Requisitos Benefícios no uso de ferramentas: ●Gerenciar versões e alterações ●Armazenar atributos dos requisitos ●Facilidade na análise de impacto ●Rastrear o status do requisito ●Controle de acesso ●Comunicação com stakeholders ●Reutilização de requisitos
  • 25.
    Ferramentas para Gerênciade Requisitos Esses produtos são classificados como ferramentas de gerenciamento de requisitos e não como ferramentas de desenvolvimento de requisitos.
  • 26.
    Ferramentas para Gerênciade Requisitos Estas ferramentas não substituem um processo definido que os membros da equipe seguem para elicitar e gerenciar requisitos. É sugerido usar uma ferramenta quando já se tem uma abordagem que funciona mas que requer maior eficiência pois uma ferramenta não compensa a falta de processo, disciplina, experiência e entendimento.
  • 27.
    Ferramentas para Gerênciade Requisitos Exemplos de ferramentas: IBM Rational RequisitePro Borland CaliberRM HP Quality Center
  • 28.
    Ferramentas para Gerênciade Requisitos IBM Rational RequisitePro
  • 29.
    Ferramentas para Gerênciade Requisitos Borland CaliberRM
  • 30.
    Ferramentas para Gerênciade Requisitos HP Quality Center
  • 31.
    Ferramentas para Gerênciade Requisitos Sites de ferramentas: Volere: www.volere.co.uk INCOSE: www.incose.org Tigris.org: www.tigris.org
  • 32.
    Ferramentas para Gerênciade Requisitos Volere: www.volere.co.uk
  • 33.
    Ferramentas para Gerênciade Requisitos INCOSE: www.incose.org
  • 34.
    Ferramentas para Gerênciade Requisitos Tigris.org: www.tigris.org
  • 35.
  • 36.
    Conclusão Evolução dos Requisitos MelhorCompreensão do Problema Redefinição de Prioridades Mudanças no Ambiente
  • 37.
    Conclusão Gerência de Requisitos Gerenciamentode Mudanças Rastreabilidade Ferramentas CASE apoiada por apoiado por
  • 38.
    Conclusão Gerência de Requisitos Gerenciamentode Mudanças Rastreabilidade Ferramentas CASE apoiada por apoiado por Planejamento Definir Processo Definir Política Selecionar
  • 39.
    Referências (1 de3) ATLANTIC SYSTEMS GUILD LTDA. Volere Requirements Resources: Requirements Tools. Disponível em: <http://www. volere.co.uk/tools.htm>. Acesso em: 25/04/2010. BLASCHEK, José Roberto. Gerência de Requisitos: O principal problema dos projetos de software. Disponível em: <http: //www.bfpug.com.br/islig-rio/jun-2002.htm>. Acesso em: 25/04/2010. BORLAND. CaliberRM: enterprise software requirements management system. Disponível em <http://www.borland. com/us/products/caliber/index.html>. Acesso em: 28/04/2010.
  • 40.
    Referências (2 de3) HEWLETT-PACKARD. HP Quality Center. Disponível em: <https://h10078.www1.hp. com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1- 11-127-24_4000_100__>. Acesso em: 28/04/2010. IBM. Rational RequisitePro: a requirements management tool. Disponível em: <http://www-01.ibm. com/software/awdtools/reqpro/>. Acesso em: 28/04/2010. INCOSE. INCOSE Requirements Management Tools Survey. Disponível em: <http://www.incose. org/ProductsPubs/products/rmsurvey.aspx>. Acesso em: 27/04/2010.
  • 41.
    Referências (3 de3) MAGELA, Rogério. Engenharia de Software Aplicada: fundamentos. Rio de Janeiro: Alta Books, 2006. SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003. TIGRIS. Software requirements management tools. Disponível em: <http://requirements.tigris.org/>. Acesso em: 01/05/2010. WIEGERS, Karl E. Software Requirements. 2ª ed. Washington, USA: Microsoft Press, 2003.