Engenharia de Software

Transcrição

1 Engenharia de Software Engenharia de Requisitos Departamento de Matemática Universidade dos Açores Hélia Guerra

2 A importância dos requisitos 2

3 A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. 2

4 A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. 2

5 A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work is so cripples the resulting systems if done wrong. 2

6 A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work is so cripples the resulting systems if done wrong. No other part is more difficult to rectify later. 2

7 A importância dos requisitos The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems. No other part of the work is so cripples the resulting systems if done wrong. No other part is more difficult to rectify later. 2 (Brooks, 1987)

8 factores com maior impacto na falha de projectos 3

9 factores com maior impacto na falha de projectos Requisitos incompletos 3

10 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores 3

11 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas 3

12 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo 3

13 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações 3

14 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações Falta de planeamento 3

15 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações Falta de planeamento Sistema já não é preciso 3

16 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações Falta de planeamento Sistema já não é preciso Os requisitos estão envolvidos na maior parte das causas da falha de projectos 3

17 factores com maior impacto na falha de projectos Requisitos incompletos Falta de envolvimento dos utilizadores Expectativas pouco realistas Falta de suporte executivo Alterações aos requisitos e às especificações Falta de planeamento Sistema já não é preciso Os requisitos estão envolvidos na maior parte das causas da falha de projectos Erros de requisitos podem sair caros se não forem detectados a tempo 3

18 requisitos 4

19 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema 4

20 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com 4

21 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com entidades ou objectos 4

22 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com entidades ou objectos o estado em que cada entidade pode estar 4

23 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com entidades ou objectos o estado em que cada entidade pode estar as funções que devem ser executadas para que as entidades mudem de estado ou as características dos objectos se alterem 4

24 requisitos Um requisito é uma expressão do comportamento pretendido para o sistema Um requisito lida com entidades ou objectos o estado em que cada entidade pode estar as funções que devem ser executadas para que as entidades mudem de estado ou as características dos objectos se alterem Os requisitos focam as necessidades dos clientes e não a solução ou a implementação do sistema 4

25 processo para capturar os requisitos 5

26 processo para capturar os requisitos Feito por um analista de requisitos ou analista de sistemas 5

27 processo para capturar os requisitos Feito por um analista de requisitos ou analista de sistemas O passo final é um documento com a especificação dos requisitos 5

28 Levantamento de requisitos 6

29 Levantamento de requisitos Os clientes nem sempre exprimem bem as suas necessidades e os seus problemas 6

30 Levantamento de requisitos Os clientes nem sempre exprimem bem as suas necessidades e os seus problemas É importante discutir os requisistos com todas as pessoas envolvidas no sistema 6

31 Levantamento de requisitos Os clientes nem sempre exprimem bem as suas necessidades e os seus problemas É importante discutir os requisistos com todas as pessoas envolvidas no sistema É importante chegar a um acordo sobre os requisistos 6

32 Levantamento de requisitos Os clientes nem sempre exprimem bem as suas necessidades e os seus problemas É importante discutir os requisistos com todas as pessoas envolvidas no sistema É importante chegar a um acordo sobre os requisistos se não houver acordo, o projecto está condenado ao fracasso 6

33 As fontes dos requisitos 7

34 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido 7

35 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto 7

36 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema 7

37 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema Peritos no domínio: familiarizados com o problema que vai ser resolvido 7

38 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema Peritos no domínio: familiarizados com o problema que vai ser resolvido Gestores de negócios: conduzem estudos para encontrar tendencias futuras e potenciais necessidades dos compradores 7

39 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema Peritos no domínio: familiarizados com o problema que vai ser resolvido Gestores de negócios: conduzem estudos para encontrar tendencias futuras e potenciais necessidades dos compradores Advogados ou auditores: familiarizados com a lei e com o governo 7

40 As fontes dos requisitos Clientes: pagam para o software ser desenvolvido Compradores: compram o software depois de pronto Utilizadores: utilizam o sistema Peritos no domínio: familiarizados com o problema que vai ser resolvido Gestores de negócios: conduzem estudos para encontrar tendencias futuras e potenciais necessidades dos compradores Advogados ou auditores: familiarizados com a lei e com o governo Engenheiros de Software ou outros especialista em tencologias 7

41 pontos de vista 8

42 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento 8

43 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos 8

44 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros 8

45 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores 8

46 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem 8

47 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem 8

48 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem querem as coisas prontas rapidamente 8

49 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem querem as coisas prontas rapidamente não conseguem atribuir prioridades às necessidades 8

50 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem querem as coisas prontas rapidamente não conseguem atribuir prioridades às necessidades não aceitam assumir responsabilidades no sistema 8

51 pontos de vista Cada interveniente tem uma visão própria do sistema e do seu funcionamento Diferentes intervenientes podem querer diferentes níveis de detalhe para os requisitos Por vezes existem ideias pré-concebidas de uns intervenientes em relação a outros Equipa de desenvolvimento -> utilizadores não sabem bem o que querem não explicam bem o que querem querem as coisas prontas rapidamente não conseguem atribuir prioridades às necessidades não aceitam assumir responsabilidades no sistema... 8

52 pontos de vista 9

53 pontos de vista Utilizadores -> Equipa de desenvolvimento 9

54 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais 9

55 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos 9

56 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara 9

57 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados 9

58 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados ultrapassam sempre o orçamento previsto 9

59 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados ultrapassam sempre o orçamento previsto pedem aos utilizadores tarefas que os desviam da sua tarefa principal 9

60 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados ultrapassam sempre o orçamento previsto pedem aos utilizadores tarefas que os desviam da sua tarefa principal... 9

61 pontos de vista Utilizadores -> Equipa de desenvolvimento não as necessidades operacionais dão demasiada importância aos aspectos técnicos não conseguem implementar requisitos de forma clara estão sempre atrasados ultrapassam sempre o orçamento previsto pedem aos utilizadores tarefas que os desviam da sua tarefa principal... O analista de requisitos deve ter uma excelente habilidade nas relações sociais entre os diferentes intervenientes, bem como ter sólidos conhecimentos técnicos 9

62 Formas de levantamento de requisitos 10

63 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema 10

64 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível 10

65 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) 10

66 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) Aprender com os utilizadores as suas tarefas 10

67 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) Aprender com os utilizadores as suas tarefas Entrevistar grupos de intervenientes em conjunto 10

68 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) Aprender com os utilizadores as suas tarefas Entrevistar grupos de intervenientes em conjunto Usar estratégias de domínio especificas, tais como, a Joint Application Design 10

69 Formas de levantamento de requisitos Entrevistar os intervenientes no sistema Revisão da documentação disponível Observação do sistema existente (se aplicável) Aprender com os utilizadores as suas tarefas Entrevistar grupos de intervenientes em conjunto Usar estratégias de domínio especificas, tais como, a Joint Application Design Brainstorming com utilizadores correntes e potenciais utilizadores 10

70 modelo de requisitos de volere 11

71 tipos de requisitos 12

72 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente 12

73 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz 12

74 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação 12

75 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação Transformações nos dados 12

76 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação Transformações nos dados Reacções esperadas a estímulos externos 12

77 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação Transformações nos dados Reacções esperadas a estímulos externos Formato dos dados de I/O 12

78 tipos de requisitos Funcionais: descrevem a interacção entre o sistema e o seu ambiente O que faz o sistema e quando faz Modos de operação Transformações nos dados Reacções esperadas a estímulos externos Formato dos dados de I/O... 12

79 tipos de requisitos 13

80 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter 13

81 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) 13

82 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) 13

83 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) 13

84 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) 13

85 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) 13

86 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) Precisão 13

87 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) Precisão Tempo para entrega 13

88 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) Precisão Tempo para entrega Custo 13

89 tipos de requisitos Qualidade ou não funcionais: descrevem qualidades/características que o software deve ter Desempenho (tempo de resposta) Utilização (fácil, tempo de treino) Segurança (acesso restrito, dados isolados, roubo e vandalismo) Fiabilidade e portabilidade (capacidade em detectar e isolar falhas, frequencia de backups, copias em diferentes locais) Manuntenção (corrigir erros, melhorar o sistema, facilidade) Precisão Tempo para entrega Custo... 13

90 tipos de requisitos 14

91 tipos de requisitos Restrições ao desenho: decisão de desenho 14

92 tipos de requisitos Restrições ao desenho: decisão de desenho Ambiente físico (plataforma, local ou distribuido, temperatura, humidade, dimensão, linguagens de programação) 14

93 tipos de requisitos Restrições ao desenho: decisão de desenho Ambiente físico (plataforma, local ou distribuido, temperatura, humidade, dimensão, linguagens de programação) Interfaces (componentes da interface, sistemas de input, sistemas de output) 14

94 tipos de requisitos Restrições ao desenho: decisão de desenho Ambiente físico (plataforma, local ou distribuido, temperatura, humidade, dimensão, linguagens de programação) Interfaces (componentes da interface, sistemas de input, sistemas de output) Utilizadores (quem são, tipos, conhecimentos que têm) 14

95 tipos de requisitos Restrições ao desenho: decisão de desenho Ambiente físico (plataforma, local ou distribuido, temperatura, humidade, dimensão, linguagens de programação) Interfaces (componentes da interface, sistemas de input, sistemas de output) Utilizadores (quem são, tipos, conhecimentos que têm)... 14

96 tipos de requisitos 15

97 tipos de requisitos 15

98 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar 15

99 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar Recursos (materiais, pessoas, outros) 15

100 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar Recursos (materiais, pessoas, outros) Documentação (tipo, online/offline, livro) 15

101 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar Recursos (materiais, pessoas, outros) Documentação (tipo, online/offline, livro) Standards 15

102 tipos de requisitos Restrições ao processo: decisão das técnicas e recursos a usar Recursos (materiais, pessoas, outros) Documentação (tipo, online/offline, livro) Standards... 15

103 resolução de conflitos 16

104 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes 16

105 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias 16

106 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias Atribuir prioridades aos requisitos 16

107 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias Atribuir prioridades aos requisitos essencial: têm que ser satisfeitos 16

108 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias Atribuir prioridades aos requisitos essencial: têm que ser satisfeitos desejável: seria bom que fossem satisfeitos 16

109 resolução de conflitos Diferentes intervenientes no sistema podem ter ideias diferentes surgem potenciais conflitos de ideias Atribuir prioridades aos requisitos essencial: têm que ser satisfeitos desejável: seria bom que fossem satisfeitos opcional: podem ser satisfeitos mas é possível eliminá-los 16

110 documentação dos requisitos 17

111 documentação dos requisitos Definição dos requisitos: listagem de tudo o que o cliente quer encontrar feito 17

112 documentação dos requisitos Definição dos requisitos: listagem de tudo o que o cliente quer encontrar feito descreve as entidades do ambiente onde o sistema vai ser instalado 17

113 documentação dos requisitos Definição dos requisitos: listagem de tudo o que o cliente quer encontrar feito descreve as entidades do ambiente onde o sistema vai ser instalado Especificação dos requisitos: reescrita do documento anterior utilizando termos técnicos adequados à equipa de desenvolvimento 17

114 características dos requisitos 18

115 características dos requisitos Correcção 18

116 características dos requisitos Correcção Consistencia 18

117 características dos requisitos Correcção Consistencia Coerencia 18

118 características dos requisitos Correcção Consistencia Coerencia Completude 18

119 características dos requisitos Correcção Consistencia Coerencia Completude Viabilidade 18

120 características dos requisitos Correcção Consistencia Coerencia Completude Viabilidade Relevancia 18

121 características dos requisitos Correcção Consistencia Coerencia Completude Viabilidade Relevancia Certificação 18

122 características dos requisitos Correcção Consistencia Coerencia Completude Viabilidade Relevancia Certificação Rastreabilidade (Traceability) 18

123 Modelaçãode requisitos 19

124 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões 19

125 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos 19

126 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais 19

127 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais Diagramas entidade relacionamento 19

128 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais Diagramas entidade relacionamento Máquinas de estados 19

129 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais Diagramas entidade relacionamento Máquinas de estados Traços de eventos 19

130 Modelaçãode requisitos É importante usar notações standard para modelar, documentar e comunicar decisões A modelação é útil para se perceber os requisitos Vamos estudar os seguintes paradigmas notacionais Diagramas entidade relacionamento Máquinas de estados Traços de eventos Diagramas de fluxo de dados 19

131 diagramas entidaderelacionamento 20

132 diagramas entidaderelacionamento Ehen,

133 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais 20

134 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais Construtores 20

135 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais Construtores entidades: representam colecções de objectos reais (carros, moedas,...) 20

136 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais Construtores entidades: representam colecções de objectos reais (carros, moedas,...) relacionamentos: ligações entre entidades 20

137 diagramas entidaderelacionamento Ehen, 1976 Paradigma de notação bastante popular para representar modelos conceptuais Construtores entidades: representam colecções de objectos reais (carros, moedas,...) relacionamentos: ligações entre entidades atributos: anotações feitas nas entidades para descreverem propriedades 20

138 diagramas entidaderelacionamento 21

139 diagramas entidaderelacionamento 22

140 diagramas entidaderelacionamento Os diagramas ER fornecem uma visão relativamente estável do problema 22

141 diagramas entidaderelacionamento Os diagramas ER fornecem uma visão relativamente estável do problema Alterar requisitos significa alterar entidades, atributos e relacionamentos 22

142 diagramas entidaderelacionamento Os diagramas ER fornecem uma visão relativamente estável do problema Alterar requisitos significa alterar entidades, atributos e relacionamentos Contudo, pode não ser simples saber qual o nível de detalhe para modelar um problema, nem se determinados dados são entidades ou atributos 22

143 diagramas entidaderelacionamento Os diagramas ER fornecem uma visão relativamente estável do problema Alterar requisitos significa alterar entidades, atributos e relacionamentos Contudo, pode não ser simples saber qual o nível de detalhe para modelar um problema, nem se determinados dados são entidades ou atributos Os diagramas devem ser usados na fase inicial do processo de requisitos 22

144 UML 23

145 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos 23

146 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos 23

147 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos Diagramas UML 23

148 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos Diagramas UML Visão estática do sistema (classes, componentes, instalação) 23

149 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos Diagramas UML Visão estática do sistema (classes, componentes, instalação) Visão dinâmica do sistema (casos de uso, actividades, interação, estados) 23

150 UML UML (Unified Modeling Language) é uma notação muito usada para descrever soluções orientadas a objectos A UML foi adoptada pela OMG (Object Management Group) como a notação standard orientada a objectos Diagramas UML Visão estática do sistema (classes, componentes, instalação) Visão dinâmica do sistema (casos de uso, actividades, interação, estados) 23

151 Diagramas de classes UML 24

152 Diagramas de classes UML O diagrama de classes está presente em qualquer modelo especificado usando a UML 24

153 Diagramas de classes UML O diagrama de classes está presente em qualquer modelo especificado usando a UML É um diagrama ER que relaciona classes (entidades) 24

154 Diagramas de classes UML O diagrama de classes está presente em qualquer modelo especificado usando a UML É um diagrama ER que relaciona classes (entidades) Resulta de um processo de abstracção através do qual se identificam os objectos (entidades e conceitos) relevantes para sistema e se procuram descrever propriedades (atributos) e comportamentos (operações) desses objectos 24

155 Diagrama de classes 25

156 diagrama de classes 26

157 diagrama de classes Agregação relação has-a 26

158 diagrama de classes Agregação relação has-a Composição relação de agregação mais forte 26

159 diagrama de classes Agregação relação has-a Composição relação de agregação mais forte Generalização relação is-a 26

160 máquinas de estados 27

161 máquinas de estados Descrição gráfica do diálogo entre o sistema e o ambiente 27

162 máquinas de estados Descrição gráfica do diálogo entre o sistema e o ambiente Nó (estado) representa um conjunto de condições estáveis existentes entre uma ocorrencia de eventos 27

163 máquinas de estados Descrição gráfica do diálogo entre o sistema e o ambiente Nó (estado) representa um conjunto de condições estáveis existentes entre uma ocorrencia de eventos Aresta (transição) representa uma alteração ao comportamento devido à ocorrencia de um evento 27

164 máquinas de estados Descrição gráfica do diálogo entre o sistema e o ambiente Nó (estado) representa um conjunto de condições estáveis existentes entre uma ocorrencia de eventos Aresta (transição) representa uma alteração ao comportamento devido à ocorrencia de um evento Útil para especificar como é que o sistema se comporta em resposta a determinada sequencia de eventos 27

165 máquinas de estados 28

166 máquinas de estados 29

167 máquinas de estados caminho: sequencia de eventos observáveis pelo ambiente que se inicia no estado inicial 29

168 máquinas de estados caminho: sequencia de eventos observáveis pelo ambiente que se inicia no estado inicial máquina de estados determinista: para cada estado e cada evento só existe uma transição 29

169 Diagramas UML de estados 30

170 Diagramas UML de estados 31

171 Diagramas UML de estados 32

172 Diagramas UML de estados Estados com anotações 32

173 estados 33

174 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados 33

175 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: 33

176 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: - classes de equivalencia de possível comportamento 33

177 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: - classes de equivalencia de possível comportamento - Intervalos de tempo entre eventos consecutivos 33

178 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: - classes de equivalencia de possível comportamento - Intervalos de tempo entre eventos consecutivos - Pontos de controlo identificados na evolução do objecto 33

179 estados A parte mais difícil na construção dos diagramas de estados e saber como decompor o comportamento de um objecto em estados Estados são: - classes de equivalencia de possível comportamento - Intervalos de tempo entre eventos consecutivos - Pontos de controlo identificados na evolução do objecto - Partições do comportamento do objecto 33

180 Traços 34

181 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente 34

182 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente Linha vertical: linha do tempo para cada entidade indicada no topo 34

183 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente Linha vertical: linha do tempo para cada entidade indicada no topo Linha horizontal: evento ou interacção entre duas entidades nos extremos da linha 34

184 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente Linha vertical: linha do tempo para cada entidade indicada no topo Linha horizontal: evento ou interacção entre duas entidades nos extremos da linha O tempo progride do topo para a base 34

185 Traços Descrição gráfica de sequencias de eventos trocados entre as entidades e o ambiente Linha vertical: linha do tempo para cada entidade indicada no topo Linha horizontal: evento ou interacção entre duas entidades nos extremos da linha O tempo progride do topo para a base Um gráfico descreve um único traço de eventos, representando um comportamento possível do sistema 34

186 Traços 35

187 Traços Exemplo: comportamento típico à esquerda e comportamento atípico à direita 35

188 Diagramas de fluxo de dados 36

189 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível 36

190 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível um processo é representado uma uma elipse 36

191 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível um processo é representado uma uma elipse fluxo de dados é representado por uma seta 36

192 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível um processo é representado uma uma elipse fluxo de dados é representado por uma seta armazém de dados é um repositório de dados 36

193 Diagramas de fluxo de dados Um diagrama de fluxo de dados (DFD) modela a funcionalidade e o fluxo de dados de uma função para outra numa visão do sistema de alto nível um processo é representado uma uma elipse fluxo de dados é representado por uma seta armazém de dados é um repositório de dados actor entidade que fornece ou recebe dados é representada por um rectângulo 36

194 Diagrama de fluxo de dados 37

195 Diagramas de fluxo de dados 38

196 Diagramas de fluxo de dados Vantagens: 38

197 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos 38

198 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos fácil leitura e entendimento 38

199 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos fácil leitura e entendimento Desvantagem: 38

200 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos fácil leitura e entendimento Desvantagem: podem ser ambíguos para quem não esteja familiarizado com o problema 38

201 Diagramas de fluxo de dados Vantagens: modelo intuitivo da funcionalidade de um sistema numa visão de alto nível e da dependencia dos dados entre os vários processos fácil leitura e entendimento Desvantagem: podem ser ambíguos para quem não esteja familiarizado com o problema Devem ser usados numa fase inicial, quando os detalhes ainda não são importantes 38

202 Diagramas UmL de casos de uso 39

203 Diagramas UmL de casos de uso Componentes 39

204 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande 39

205 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande actores (pessoas, sistemas): figuras do lado de fora do rectangulo: 39

206 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande actores (pessoas, sistemas): figuras do lado de fora do rectangulo: caso de uso: elipse dentro dos limites do sistema que representa uma funcionalidade 39

207 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande actores (pessoas, sistemas): figuras do lado de fora do rectangulo: caso de uso: elipse dentro dos limites do sistema que representa uma funcionalidade linha entre um actor e um caso de uso, indicando que o actor participa no caso de uso 39

208 Diagramas UmL de casos de uso Componentes limites do sistema: rectangulo grande actores (pessoas, sistemas): figuras do lado de fora do rectangulo: caso de uso: elipse dentro dos limites do sistema que representa uma funcionalidade linha entre um actor e um caso de uso, indicando que o actor participa no caso de uso Os casos de uso são usados para especificar comportamentos importantes do sistema do ponto de vista do utilizador 39

209 Diagrama UmL de casos de uso 40

210 Linguagem de especificação de requisitos 41

211 Linguagem de especificação de requisitos Combina vários paradigmas notacionais 41

212 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem 41

213 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) 41

214 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) diagramas de classes (diagramas ER) 41

215 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) diagramas de classes (diagramas ER) diagramas de sequencias (traços) 41

216 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) diagramas de classes (diagramas ER) diagramas de sequencias (traços) diagramas de colaboração (traços) 41

217 Linguagem de especificação de requisitos Combina vários paradigmas notacionais Por exemplo, a notação UML tem diagramas de casos de uso (DFD de alto nível) diagramas de classes (diagramas ER) diagramas de sequencias (traços) diagramas de colaboração (traços) diagramas de estados (máquinas de estados) 41

218 prototipos de requisitos 42

219 prototipos de requisitos Para levantar requisitos de um sistema 42

220 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores 42

221 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados 42

222 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados que funcionalidades não são úteis 42

223 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados que funcionalidades não são úteis que funcionalidades é que faltam 42

224 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados que funcionalidades não são úteis que funcionalidades é que faltam Determinar se o problema do cliente tem uma solução viável 42

225 prototipos de requisitos Para levantar requisitos de um sistema Pedir aos clientes/utilizadores que aspectos gostariam de ver melhorados que funcionalidades não são úteis que funcionalidades é que faltam Determinar se o problema do cliente tem uma solução viável Optimizar a qualidade dos requisitos 42

226 prototipo de requisitos 43

227 Abordagens para a prototipagem de requisitos 44

228 Abordagens para a prototipagem de requisitos Descartável 44

229 Abordagens para a prototipagem de requisitos Descartável serve apenas para perceber o problema e não é integrada no produto final 44

230 Abordagens para a prototipagem de requisitos Descartável serve apenas para perceber o problema e não é integrada no produto final Evolucionária 44

231 Abordagens para a prototipagem de requisitos Descartável serve apenas para perceber o problema e não é integrada no produto final Evolucionária Para além de ajudar a perceber o problema também é incorporada no produto final 44

232 Abordagens para a prototipagem de requisitos Descartável serve apenas para perceber o problema e não é integrada no produto final Evolucionária Para além de ajudar a perceber o problema também é incorporada no produto final Prototipagem rápida 44

233 Prototipagem vs. modelação 45

234 Prototipagem vs. modelação Prototipagem 45

235 Prototipagem vs. modelação Prototipagem boa para responder a questões relacionadas com as interfaces com o utilizador 45

236 Prototipagem vs. modelação Prototipagem boa para responder a questões relacionadas com as interfaces com o utilizador Modelação 45

237 Prototipagem vs. modelação Prototipagem boa para responder a questões relacionadas com as interfaces com o utilizador Modelação boa para responder a questões relacionadas com a ordem em que os eventos ocorrem ou com a sincronização de actividades 45

238 Normas IEEE,

239 Normas IEEE, 1998 Table of contents 46

240 Normas IEEE, 1998 Table of contents 1.Introduction 46

241 Normas IEEE, 1998 Table of contents 1.Introduction 1.1. Purpose 46

242 Normas IEEE, 1998 Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 46

243 Normas IEEE, 1998 Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 46

244 Normas IEEE, 1998 Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 1.4. References 46

245 Normas IEEE, 1998 Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms, and abbreviations 1.4. References 1.5. Overview 46

246 Normas IEEE,

247 Normas IEEE, Overall description 47

248 Normas IEEE, Overall description 2.1. Product perspective 47

249 Normas IEEE, Overall description 2.1. Product perspective 2.2. Product functions 47

250 Normas IEEE, Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 47

251 Normas IEEE, Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 47

252 Normas IEEE, Overall description 2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5.Assumptions and dependencies 47

253 Normas IEEE,

254 Normas IEEE, Specific requirements 48

255 Normas IEEE, Specific requirements 3.1. External interfaces 48

256 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 48

257 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 48

258 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 48

259 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 3.5. Design constraints 48

260 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 3.5. Design constraints 3.6. Software system attributes 48

261 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 3.5. Design constraints 3.6. Software system attributes 3.7. Organizing the specific requirements 48

262 Normas IEEE, Specific requirements 3.1. External interfaces 3.2. Functions 3.3. Performance requirements 3.4. Logical database requirements 3.5. Design constraints 3.6. Software system attributes 3.7. Organizing the specific requirements 3.8. Additional comments 48

263 Normas IEEE,

264 Normas IEEE, 1998 Appendixes 49

265 Normas IEEE, 1998 Appendixes Index 49

266 Normas IEEE, 1998 Appendixes Index 49

267 validação e verificação 50

268 validação e verificação Na validação dos requisitos verifica-se se a definição dos requisitos reflecte as necessidades do cliente 50

269 validação e verificação Na validação dos requisitos verifica-se se a definição dos requisitos reflecte as necessidades do cliente Na verificação dos requisitos verifica-se se o documento da definição dos requisitos está de acordo com o documento da especificação dos requisitos 50

270 validação e verificação Na validação dos requisitos verifica-se se a definição dos requisitos reflecte as necessidades do cliente Na verificação dos requisitos verifica-se se o documento da definição dos requisitos está de acordo com o documento da especificação dos requisitos A validação garante que we build the right system 50

271 validação e verificação Na validação dos requisitos verifica-se se a definição dos requisitos reflecte as necessidades do cliente Na verificação dos requisitos verifica-se se o documento da definição dos requisitos está de acordo com o documento da especificação dos requisitos A validação garante que we build the right system A verificação garante que we build the system right 50

272 técnicas para validação 51

273 técnicas para validação Curzamento de informação 51

274 técnicas para validação Curzamento de informação Leitura 51

275 técnicas para validação Curzamento de informação Leitura Entrevistas 51

276 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões 51

277 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação 51

278 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações 51

279 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações Cenários 51

280 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações Cenários Protótipos 51

281 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações Cenários Protótipos Simulação 51

282 técnicas para validação Curzamento de informação Leitura Entrevistas Revisões Listas de verificação Modelos pré-definidos para verificar funções e relações Cenários Protótipos Simulação Demonstração matemática 51

283 revisão dos requisitos 52

284 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema 52

285 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos 52

286 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos Revisão do ambiente onde o sistem irá funcionar 52

287 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos Revisão do ambiente onde o sistem irá funcionar Revisão do fluxo de informação e das funções propostas 52

288 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos Revisão do ambiente onde o sistem irá funcionar Revisão do fluxo de informação e das funções propostas Estimação e docmentação do risco, discussão e alternativas 52

289 revisão dos requisitos Revisão dos objectivos estabelecidos e dos objectivos do sistema Comparação dos requisitos com os objectivos Revisão do ambiente onde o sistem irá funcionar Revisão do fluxo de informação e das funções propostas Estimação e docmentação do risco, discussão e alternativas Testes ao sistema: como é que os requisitos irão ser revalidados à medida que se fazem alterações 52

290 técnicas para verificação 53

291 técnicas para verificação Cruzamento de informação 53

292 técnicas para verificação Cruzamento de informação Simulação 53

293 técnicas para verificação Cruzamento de informação Simulação Verificação de consistencia 53

294 técnicas para verificação Cruzamento de informação Simulação Verificação de consistencia Verificação de completude 53

295 técnicas para verificação Cruzamento de informação Simulação Verificação de consistencia Verificação de completude Verificação de estados/transições inatingíveis 53

296 técnicas para verificação Cruzamento de informação Simulação Verificação de consistencia Verificação de completude Verificação de estados/transições inatingíveis Model checking 53