Gerência de Requisitos

6,235 views
5,932 views

Published on

Este trabalho explana sobre a atividade de Gerência de Requisitos que é o processo de compreender e controlar as mudanças nos requisitos de sistemas.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,235
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
166
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Gerência de Requisitos

  1. 1. Gerência de RequisitosDisciplina Engenharia de SoftwareMauricio Volkweis AstiazaraMirela Ferreira CésarPorto Alegre, maio de 2010
  2. 2. SumárioEvolução dos RequisitosConceito de Gerência de RequisitosGerenciamento de Mudanças de RequisitosRastreabilidade de RequisitosPlanejamento da Gerência de RequisitosFerramentas para Gerência de RequisitosConclusão
  3. 3. Evolução dos RequisitosRequisitos costumam sofrer modificações porque o problemapara o qual se refere o requisito não foi inteiramente definido,os requisitos do sistema são necessariamente incompletos.
  4. 4. Evolução dos RequisitosPor que os requisitos mudam?● Porque durante o processo de software o entendimento dosdesenvolvedores vai se modificando.● No aperfeiçoamento de um sistema antigo ou automatização de umprocesso manual podem surgir novos requisitos.● Quando os usuários se familiarizam com o sistema, novosrequisitos surgem pelas seguintes razões:○ A comunidade de usuários é diversificada;○ O pessoal que paga por um sistema e os usuários dessesistema raramente são as mesmas pessoas e;○ A empresa e o ambiente técnico do sistema se modificam, e issotem de ser refletido no próprio sistema.
  5. 5. Evolução dos RequisitosEvolução dos Requisitos. Adaptado de SOMMERVILLE, 2003.Compreensãoinicial do problemaCompreensãomodificada doproblemaRequisitosIniciaisRequisitosModificados
  6. 6. Evolução dos RequisitosNa perspectiva de evolução, os requisitos podem serclassificados como:●Voláteis●Permanentes
  7. 7. ConceitoGerência de Requisitos é oprocesso de compreender econtrolar as mudanças nosrequisitos de sistemas.
  8. 8. Gerenciamento de Mudanças deRequisitosAlteração no sistema e depois nos requisitos faz com queespecificação e implementação se desajustem.Se este tipo de situação acontecer, os requisitos cairão emdescrédito e serão relegados a segundo plano.Deve ser adotado um processo de gerenciamento demudanças.
  9. 9. Gerenciamento de Mudanças deRequisitosA vantagem de utilizar um processo formal para ogerenciamento de mudanças é que todas as propostas demudança são tratadas de modo consistente e que asmudanças no documento de requisitos são feitas de maneiracontrolada (SOMMERVILLE, 2003).
  10. 10. Gerenciamento de Mudanças deRequisitosHá 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. 11. Gerenciamento de Mudanças deRequisitosProblemaidentificado Análise do problema eespecificação da mudançaAnálise e custo da mudançaImplementação demudançasRequisitos eoutros artefatosrevisados
  12. 12. Gerenciamento de Mudanças deRequisitosUm dos principais problemas de um projeto é gerenciar oescopo. Facilmente a correta gerência de escopo é perdida.O escopo deve ser modificado com a anuência de todos osenvolvidos.Os requisitos macro representam diretamente um eventualaumento de escopo. Os requisitos macro que implicam novoscasos de uso devem ser inseridos somente se aprovados pelofinanciador do projeto (MAGELA, 2006).
  13. 13. Gerenciamento de Mudanças deRequisitosRequisitos 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 comodata, projeto, usuário solicitante e motivo.Realizar esta tarefa sem uso de ferramentas é bastantetrabalhoso (MAGELA, 2006).
  14. 14. Rastreabilidade de RequisitosA facilidade de rastreamento é uma propriedade geral de umaespecificação de requisitos que reflete a facilidade de seencontrar requisitos relacionados.Os requisitos devem obrigatoriamente possuir rastreabilidadepara trás (origem) e para frente (projeto) para garantir aqualidade e consistência da especificação.
  15. 15. Rastreabilidade de Requisitos●A rastreabilidade apoia a gerência de mudanças.●Quando são propostas modificações, é preciso verificar oimpacto dessas mudanças sobre outros requisitos e oprojeto do sistema.●As informações sobre facilidade de rastreamento são,frequentemente representadas com o uso de matrizes defacilidade de rastreamento
  16. 16. Matriz de RastreabilidadeRastreabilidade de RequisitosID doRequisito1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.21.1 U R1.2 U R U1.3 R R2.1 R U U2.2 U2.3 R U3.1 R3.2 RA dependência entre osrequisitos é registrada nainterseção da linha coma coluna.Neste exemplo, "U"indica que o requisito dalinha utiliza recursosespecificados norequisito da coluna, e "R"para indicar umrelacionamento fracoentre os requisitos.
  17. 17. Rastreabilidade de RequisitosRequisitoFuncionalCasode UsoUC-1 UC-2 UC-3 UC-4RF-1 <--RF-2 <--RF-3 <--RF-4 <--RF-5 <-- <--RF-6 <--A intersecção entre doiscomponentes indica uma conexão.É possível utilizar um símbolo nacélula para indicar osentido "rastreado-para" e"rastreado-de", ou alguma outrarelação.Matriz de RastreabilidadeAlgumas 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. 18. Rastreabilidade de RequisitosRequisitodoUsuárioRequisito Funcional Elemento doSistemaCódigo Caso deTesteUC-28 catalog.query.sort Classe catalog catalog.sort() search.7search.8UC-29 catalog.query.import Classe catalog catalog.import()catalog.validate()search.12search.13search.14A rastreabilidade pode ter relações do tipo: um-para-um,um-para-muitos, ou muitos-para-muitosMatriz de Rastreabilidade
  19. 19. Rastreabilidade de RequisitosTipo de Objeto Fonte daLigaçãoTipo de Objeto Alvo daLigaçãoFonte da InformaçãoRequisito de Sistema Requisito de Software Engenheiro de SistemaCaso de Uso Requisito Funcional Analista de RequisitosRequisito Funcional Requisito Funcional Analista de RequisitosRequisito Funcional Caso de Teste Engenheiro de TesteRequisito Funcional Elemento de Arquitetura deSoftwareArquiteto de SoftwareRequisito Funcional Outros Elementos de Projeto Projetista ouDesenvolvedorElemento de Projeto Código-fonte DesenvolvedorRegra de Negócio Requisito Funcional Analista de RequisitosMatriz de Rastreabilidade - Prováveis fontes de conhecimento
  20. 20. Rastreabilidade de RequisitosRequisitosnão-funcionais nemsempre endereçam umcódigo.Exemplo derastreabilidade numaaplicação de segurançaRastreabilidade de requisitos não-funcionais
  21. 21. Planejamento da Gerência deRequisitosPrimeiro 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. 22. Planejamento da Gerência deRequisitosUma vez avaliado o impacto e custo da mudança, decisõesgerencias devem ser tomadas e podem estar apoiadas empolí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 novosrequisitos?●Será deixada, de forma consciente, menor qualidadedaquela esperada para manter o prazo?
  23. 23. Planejamento da Gerência deRequisitos●As mudanças propostas foram cuidadosamente avaliadaspor todos os envolvidos?●As decisões sobre a incorporação dessas mudanças foramtomadas pelas pessoas apropriadas?●As mudanças foram comunicadas a todos os interessados?
  24. 24. Ferramentas para Gerência deRequisitosBenefí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. 25. Ferramentas para Gerência deRequisitosEsses produtos são classificados como ferramentas degerenciamento de requisitos e não como ferramentas dedesenvolvimento de requisitos.
  26. 26. Ferramentas para Gerência deRequisitosEstas ferramentas não substituem um processo definido queos membros da equipe seguem para elicitar e gerenciarrequisitos.É sugerido usar uma ferramenta quando já se tem umaabordagem que funciona mas que requer maior eficiência poisuma ferramenta não compensa a falta de processo, disciplina,experiência e entendimento.
  27. 27. Ferramentas para Gerência deRequisitosExemplos de ferramentas:IBM Rational RequisiteProBorland CaliberRMHP Quality Center
  28. 28. Ferramentas para Gerência deRequisitosIBM Rational RequisitePro
  29. 29. Ferramentas para Gerência deRequisitosBorland CaliberRM
  30. 30. Ferramentas para Gerência deRequisitosHP Quality Center
  31. 31. Ferramentas para Gerência deRequisitosSites de ferramentas:Volere: www.volere.co.ukINCOSE: www.incose.orgTigris.org: www.tigris.org
  32. 32. Ferramentas para Gerência deRequisitosVolere: www.volere.co.uk
  33. 33. Ferramentas para Gerência deRequisitosINCOSE: www.incose.org
  34. 34. Ferramentas para Gerência deRequisitosTigris.org: www.tigris.org
  35. 35. ConclusãoatendePlanejamentoGerência deRequisitosdefineEvolução dosRequisitos
  36. 36. ConclusãoEvolução dos RequisitosMelhor Compreensão doProblemaRedefinição de PrioridadesMudanças no Ambiente
  37. 37. ConclusãoGerência de RequisitosGerenciamento de MudançasRastreabilidadeFerramentas CASEapoiada porapoiado por
  38. 38. ConclusãoGerência de RequisitosGerenciamento de MudançasRastreabilidadeFerramentas CASEapoiada porapoiado porPlanejamentoDefinir ProcessoDefinir PolíticaSelecionar
  39. 39. Referências (1 de 3)ATLANTIC SYSTEMS GUILD LTDA. Volere RequirementsResources: 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 principalproblema 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 requirementsmanagement system. Disponível em <http://www.borland.com/us/products/caliber/index.html>. Acesso em: 28/04/2010.
  40. 40. 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 ToolsSurvey. Disponível em: <http://www.incose.org/ProductsPubs/products/rmsurvey.aspx>. Acesso em:27/04/2010.
  41. 41. 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ãoPaulo: Pearson Addison Wesley, 2003.TIGRIS. Software requirements management tools. Disponívelem: <http://requirements.tigris.org/>. Acesso em: 01/05/2010.WIEGERS, Karl E. Software Requirements. 2ª ed.Washington, USA: Microsoft Press, 2003.

×