Requisitos, segunda parte. Unidade de Engenharia do Software I para o curso de METI no ISCTE-IUL no 2.º semestre do ano lectivo de 2009/2010.

1. Engenharia do Software I Manuel Menezes de Sequeira DCTI, ISCTE-IUL Manuel.Sequeira@iscte.pt, D6.02 As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.

2. Sumário Processo da engenharia de requisitos Estudos de viabilidade Eliciação e análise de requisitos Validação de requisitos Gestão de requisitos 2009/2010 2 Engenharia do Software I

3. Processos da Engenharia de Requisitos 2009/2010 3 Engenharia do Software I

4. Na aula anterior Requisitos Funcionais e não funcionais Do utilizador Do sistema Especificação da interface Documento de requisitos de software 2009/2010 4 Engenharia do Software I

5. O processo da engenharia de requisitos Estudo de viabilidade Eliciação e análise de requisitos Especificação de requisitos Relatório de viabilidade Validação de requisitos Modelos do sistema Documento de requisitos Requisitos do utilizador e do sistema 2009/2010 5 Engenharia do Software I

6. Engenharia de requisitos Especificação de requisitos Especificação dos requisitos do sistema e modelação Especificação dos requisitos do utilizador Especificação dos requisitos do negócio Eliciação dos requisitos do sistema Estudo de viabilidade Eliciação dos requisitos do utilizador Prototipagem Eliciação de requisitos Validação de requisitos Revisões Documento de requisitos do sistema 2009/2010 6 Engenharia do Software I

7. Estudos de viabilidade Decide se o sistema proposto vale a pena Estudo bem focado que verifica se sistema Contribui para objectivos da organização? Pode ser realizado usando a tecnologia existente e com o orçamento disponível? Pode ser integrado com outros sistemas em uso? 2009/2010 7 Engenharia do Software I

8. Implementação do estudo de viabilidade Baseada em Avaliação de informação (o que é necessário) Recolha de informação Redacção de relatórios Questões para membros da organização E se o sistema não fosse implementado? Quais são os problemas de processo correntes? De que forma o sistema proposto ajudará? Quais serão os problemas de integração? É necessária nova tecnologia? E que competências? O que terá o sistema de suportar? 2009/2010 8 Engenharia do Software I

9. Eliciação e análise Por vezes conhecida por eliciação de requisitos ou descoberta de requisitos Equipa técnica colabora com cliente para obter informação acerca de Domínio de aplicação Serviços a prestar pelo sistema Restrições operacionais do sistema 2009/2010 9 Engenharia do Software I

10. Eliciação e análise Pode envolver Utilizadores finais Gestores Engenheiros responsáveispela manutenção Peritos no domínio Sindicatos Etc. Partes interessadas ou Stakeholders 2009/2010 10 Engenharia do Software I

11. Parte interessada ou stakeholder Termo muito importante! Qualquer pessoa ou entidade afectada pelo sistema ou interessada nele, quer directa, quer indirectamente 2009/2010 11 Engenharia do Software I

12. Problemas da análise de requisitos Partes não sabem o que de facto querem Partes expressam requisitos usando termos próprios Partes podem ter requisitos contraditórios Factores organizacionais e políticos influenciam requisitos do sistema Requisitos mudam durante a análise Surgem novas partes Contexto do negócio muda 2009/2010 12 Engenharia do Software I

13. Espiral da análise de requisitos Prioritização e negociação Classificação e organização Documentação Descoberta 2009/2010 13 Engenharia do Software I

14. Actividades do processo de eliciação e análise de requisitos 2009/2010 Engenharia do Software I 14

15. Descoberta de requisitos Processo de Recolha de informação acerca do sistema proposto e de sistemas existentes Destilação dos requisitos do utilizador e do sistema a partir dessa informação Fontes de informação Documentação Partes interessadas no sistema Especificações de sistemas semelhantes 2009/2010 15 Engenharia do Software I

16. Partes interessadas num ATM Clientes dos bancos Representantes dos bancos Gestores dos bancos Pessoal de balcão Administradores de bases de dados Gestores de segurança Departamentos de marketing Engenheiros de manutenção de hardware e software Reguladores da banca 2009/2010 16 Engenharia do Software I

17. Pontos de vista Estruturação de requisitos representando diferentes perspectivas das partes (partes podem ser classificadas sob diferentes pontos de vista) Análise multi-perspectiva importante: Não há forma correcta única de analisar requisitos do sistema 2009/2010 17 Engenharia do Software I

18. Tipos de pontos de vista 2009/2010 Engenharia do Software I 18

19. Tipos de pontos de vista: ATM 2009/2010 Engenharia do Software I 19

20. Identificação de pontos de vista Fornecedores e consumidores de serviços do sistema Sistemas que interagem directamente com sistema Regulamentos e normas Fontes de requisitos do negócio e não funcionais Engenheiros de desenvolvimento e manutenção Marketinge outras facetas do negócio 2009/2010 20 Engenharia do Software I

21. Hierarquia de pontos de vista do LIBSYS Todos Indirectos Domínio Interacção Director da biblioteca Finanças Fornecedores Normas da interface com utilizador Sistema de classificação Utilizadores Pessoal da biblioteca Estudantes Funcionários Externos Gestores de sistemas Catalogadores 2009/2010 21 Engenharia do Software I

22. Entrevistas Formais ou informais Equipa de eliciação coloca questões às partes acerca do sistema que usam e do sistema a desenvolver Dois tipos Fechadas – Conjunto pré-definido de questões Abertas – Sem ordem de trabalhos pré-definida; explora-se uma variedade de assuntos 2009/2010 22 Engenharia do Software I

23. Entrevistas na prática Normalmente misto entre abertas e fechadas Boas para compreender o que as partes fazem e como podem interagir com o sistema Más para compreender requisitos do domínio Engenheiros de requisitos não entendem terminologia específica do domínio Algum conhecimento do domínio é tão familiar que entrevistados têm dificuldade em articulá-lo ou julgam não valer a pena fazê-lo 2009/2010 23 Engenharia do Software I

24. Entrevistadores eficazes Características Espírito aberto Bons ouvintes das partes Sem preconceitos acerca dos requisitos Incentivam entrevistado com perguntas ou propostas Não esperam que entrevistado responda a perguntas vagas (“Oque precisa?”) 2009/2010 24 Engenharia do Software I

25. Cenários Exemplos reais de possíveis utilizações do sistema Devem incluir Descrição da situação inicial Descrição do fluxo normal de eventos Descrição do que pode correr mal Informação acerca de actividades paralelas Descrição do estado final 2009/2010 25 Engenharia do Software I

26. Cenário LIBSYS 2009/2010 Engenharia do Software I 26

27. Cenário LIBSYS 2009/2010 27 Engenharia do Software I

28. Casos de uso Técnica UML baseada em cenários identificando actores e descrevendo a interacção Conjunto dos casos de uso deve cobrir todaspossíveis interacções com sistema Diagramas de sequência podem pormenorizar casos de uso mostrando sequência de processamento de eventos 2009/2010 Engenharia do Software I 28

29. Etnografia Sociólogo/antropólogo dedica tempo a observar e analisar como pessoas trabalham Pessoas não explicam seu trabalho Revela factores sociais e organizacionais importantes Mostram que trabalho é mais rico e complexo que aparente e que sugerido por modelos simples do sistema 2009/2010 Engenharia do Software I 29

30. Etnografia focalizada Combina etnografia e prototipagem Desenvolvimento de protótipos resulta em novas questões focalizando análise etnográfica 2009/2010 Engenharia do Software I 30

31. Âmbito da etnografia Requisitos derivam da forma efectiva de trabalho das pessoas e não das especificações em definições de processos Problema com a etnografia é que estuda práticas com explicação histórica que já não é relevante 2009/2010 Engenharia do Software I 31

32. Validação de requisitos Pretende demonstrar que requisitos definem sistema pretendido pelo cliente Altos custos associados a erros nosrequisitos! Validação importantíssima Corrigir erro nos requisitos depois da entrega pode custar 100 vezes mais que corrigir erro de implementação 2009/2010 Engenharia do Software I 32

33. 2009/2010 Engenharia do Software I 33 custo tempo

34. Verificação de requisitos 2009/2010 Engenharia do Software I 34

35. Técnicas de validação de requisitos 2009/2010 Engenharia do Software I 35

36. Revisões de requisitos Devem realizar-se regularmente durante formulação da definição dos requisitos Devem envolver cliente e adjudicatário Formais (documentos) ou informais Boa comunicação entre desenvolvedores, clientes e utilizadores permite resolver problemas mais cedo 2009/2010 Engenharia do Software I 36

37. Verificações das revisões 2009/2010 Engenharia do Software I 37

38. Gestão de requisitos Processo de gerir requisitos em mudança durante processo da engenharia de requisitos e desenvolvimento do sistema Requisitos inevitavelmente incompletos e inconsistentes Novos requisitos surgem durante processo devido a mudanças nas necessidades do negócio e à melhor compreensão do sistema Pontos de vista diferentes têm diferentes requisitos muitas vezes contraditórios 2009/2010 Engenharia do Software I 38

39. Os requisitos mudam Prioridades de diferentes pontos de vista mudam durante processo de desenvolvimento Clientes podem especificar requisitos sob perspectiva do negócio que colidem com requisitos de utilizadores finais Contextos do negócio e técnico mudam durante desenvolvimento do sistema 2009/2010 Engenharia do Software I 39

40. Evolução dos requisitos 2009/2010 40 Engenharia do Software I Compreensão inicial do problema Compreensão do problema modificada Requisitos iniciais Requisitos modificados tempo

41. Requisitos duradouros e voláteis 2009/2010 Engenharia do Software I 41

42. Classificação de requisitos 2009/2010 Engenharia do Software I 42

43. Classificação de requisitos 2009/2010 Engenharia do Software I 43

44. Planeamento da gestão de requisitos 2009/2010 Engenharia do Software I 44

45. Suporte em ferramentas CASE 2009/2010 Engenharia do Software I 45

46. Gestão de mudanças em requisitos Deve aplicar-se a todas as modificações de requisitos propostas Principais etapas 2009/2010 Engenharia do Software I 46

47. Gestão de mudanças em requisitos 2009/2010 47 Engenharia do Software I Análise do problema e especificação da mudança Problema identificado Documentos revistos Análise e custeio da mudança Implementação da mudança

48. A reter Processo de engenharia de requisitos inclui Estudo de viabilidade Eliciação e análise de requisitos Especificação de requisitos Gestão de requisitos Eliciação e análise de requisitos são iterativas e incluem Compreensão do domínio Recolha de requisitos Classificação de requisitos Estruturação de requisitos Prioritizaçãode requisitos Validação de requisitos 2009/2010 Engenharia do Software I 48

49. A reter Sistemas têm múltiplas partes interessadas com diferentes requisitos Factores sociais e organizacionais influenciam requisitos do sistema Validação dos requisitos verifica Validade Consistência Completude Realismo Verificabilidade 2009/2010 Engenharia do Software I 49

50. A reter Modificações no negócio conduzem inevitavelmente a mudanças nos requisitos Gestão de requisitos inclui planeamento e gestão de mudanças 2009/2010 Engenharia do Software I 50

51. A ler IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006 Capítulo 6 Capítulo 7 2009/2010 51 Engenharia do Software I