Este documento discute requisitos de engenharia de software. Apresenta tipos de requisitos funcionais e não funcionais, e discute como especificá-los de forma clara, completa e consistente para evitar ambiguidades. Também discute alternativas à especificação de requisitos em linguagem natural, como especificações estruturadas, baseadas em modelos e tabelas.

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 Requisitos Funcionais e não funcionais Do utilizador Do sistema Especificação da interface Documento de requisitos de software 2009/2010 2 Engenharia do Software I

3. Requisitos 2009/2010 3 Engenharia do Software I

4. Requisitos Um projecto de software tem origem numa ideia de Uma outra empresa Uma entidade estatal Um outro departamento Você Requisitos Indicam o que o sistema fará e com que restrições Parte fundamental da comunicação com o cliente É comum integrarem contrato entre as partes! 2009/2010 4 Engenharia do Software I

5. Engenharia de requisitos Processo de definição Dos requisitos do cliente quanto aos serviços a fornecer por um sistema Das restrições sob as quais o sistema será desenvolvido e operará A ver na próxima aula. 2009/2010 5 Engenharia do Software I

6. Tipos de requisitos Do utilizador Afirmações em língua natural bem como diagramas acerca dos serviços a fornecer pelo sistema e acerca das suas restrições operacionais Redigido para os clientes Do sistema Documento estruturado com descrições pormenorizadas das funções, serviços e restrições operacionais do sistema Define o que deve ser implementado de uma forma que lhe permite ser parte de do contrato com o cliente 2009/2010 6 Engenharia do Software I

7. Definição e especificação: exemplos Definição de requisito do utilizador “O software fornecerá formas de representar e aceder a arquivos externos criados por outras aplicações” Especificação de requisito do sistema “Serão fornecidos ao utilizador mecanismos para especificar o tipo dos arquivos externos. Cada tipo de arquivo externo poderá ter associada uma ferramenta que poderá ser aplicada a arquivos desse tipo. Cada tipo de arquivo externo poderá ser representado no ecrã do utilizador usando um ícone específico. Deverão ser fornecidos mecanismos que permitam que o utilizador especifique o ícone associado a cada tipo de arquivo. Quando o utilizador seleccionar um ícone, a ferramenta associada ao tipo de arquivo correspondente deverá ser aplicada ao arquivo representado pelo ícone seleccionado.” 2009/2010 7 Engenharia do Software I

9. Utilizadores finais

10. Engenheiros do cliente

11. Gestores de contratação

13. Engenheiros do cliente

14. Arquitectos de sistema

16. Arquitectos de sistema

17. Desenvolvedores de softwareEspecificação do desenho do software 2009/2010 8 Engenharia do Software I

18. Especificações… mas a que nível? Especificações mais próximas do utilizador são (normalmente) mas fáceis de perceber por ele… …mas mais difíceis de perceber pelo desenvolvedor… …e vice versa Cliente Requisitos do utilizador Cliente Requisitos do sistema Desenho Sistema em execução 2009/2010 9 Engenharia do Software I

19. Requisitos funcionais e não funcionais Requisitos funcionais – Declarações acerca dos serviços que o sistema deverá fornecer, da forma como deve reagir a entradas específicas e da forma como se deve comportar em situações particulares Requisitos não funcionais – Declarações acerca das restrições sobre os serviços ou funções oferecidos pelo sistema, incluindo restrições temporais, restrições no processo de desenvolvimento, normas a aplicar, etc. Requisitos de domínio – Requisitos com origem no domínio de aplicação do sistema e reflectindo características desse domínio 2009/2010 10 Engenharia do Software I

20. Requisitos funcionais Descrevem a funcionalidade ou serviços do sistema Dependem do tipo de software, dos utilizadores espectáveis e do tipo de sistema no qual o software será usado Requisitos funcionais Requisitos funcionais do utilizador – Podem ser declarações de alto nível acerca do que o sistema deve fazer Requisitos funcionais do sistema – Devem descrever os serviços do sistema em pormenor 2009/2010 11 Engenharia do Software I

21. O sistema LIBSYS Fornece uma interface única de acesso a um conjunto de bases de dados de artigos em diferentes bibliotecas Utilizadores podem procurar, descarregar e imprimir esses artigos para uso pessoal 2009/2010 12 Engenharia do Software I

22. Exemplos de requisitos funcionais “O utilizador poderá pesquisar em todo o conjunto inicial de bases de dados ou num subconjunto de bases de dados por ele definido.” “A cada encomenda será atribuído um identificador único (ORDER_ID) que o utilizador poderá copiar para a área de armazenamento permanente da conta.” “O sistema disponibilizará ao utilizador visualizadores apropriados para a leitura de documentos no arquivo de documentos.” 2009/2010 13 Engenharia do Software I

23. Imprecisão dos requisitos Considere-se a expressão “visualizadores apropriados” Intenção do utilizador – Um visualizador especializado para cada tipo específico de documento Interpretação do desenvolvedor – Um visualizador de texto que mostra o conteúdo do documento Requisitos ambíguos podem ser interpretados de forma diferente por desenvolvedores e utilizadores Requisitos imprecisos dão origem a problemas 2009/2010 14 Engenharia do Software I

24. Completude e consistência de requisitos Por princípio os requisitos devem ser simultaneamente completos e consistentes Completude – Devem incluir descrições de todas os mecanismos e funcionalidades requeridos Consistência – Não deve haver qualquer conflito ou contradição na descrição das funcionalidades e mecanismos do sistema Na prática é impossível produzir um documento de requisitos completo e consistente 2009/2010 15 Engenharia do Software I

25. Requisitos não funcionais Definem propriedades e restrições do sistema Propriedades – Requisitos de fiabilidade, tempo de resposta, armazenamento, etc. Restrições – Capacidade dos dispositivos de E/S, representações do sistema, etc. Também podem ser especificados requisitos de processo obrigando à utilização de um dado sistema CASE, de uma dada linguagem de programação ou de um dado método de desenvolvimento Requisitos não funcionais podem ser mais críticos que requisitos funcionais! Se não forem cumpridos, o sistema é inútil 2009/2010 16 Engenharia do Software I

26. Classificações não funcionais Requisitos de produto – Especificação que o sistema fornecido tem de se comportar de determinada forma, e.g., velocidade de execução ou fiabilidade Requisitos organizacionais – São consequência de políticas e procedimentos organizacionais, e.g., normas processuais usadas ou requisitos de implementação Requisitos externos – Têm origem em factores externos ao sistema e ao seu processo de desenvolvimento, e.g., requisitos de interoperabilidade ou requisitos legislativos 2009/2010 17 Engenharia do Software I

27. Tipos de requisitos não funcionais Requisitos não funcionais De produto Organizacionais Externos Eficiência Portabilidade Interoperabilidade Éticos Usabilidade Fiabilidade Legislativos Fornecimento Normas Privacidade Segurança Implementação Desempenho Espaço 2009/2010 18 Engenharia do Software I

28. Exemplos de requisitos não funcionais Requisito de produto “A interface com o utilizador do LIBSYS será implementada usando HTML simples, sem frames nem applets Java.” Requisito organizacional “O processo de desenvolvimento do sistema e os documentos entregáveis estarão de acordo com o processo de entregáveis definidos no XYZCo-SP-STAN-95.” Requisito externo “O sistema não revelará aos operadores do sistema qualquer informação pessoal acerca dos clientes para além do seu nome e número de referência.” 2009/2010 19 Engenharia do Software I

29. Metas e requisitos Requisitos não funcionais podem ser muito difíceis de especificar com precisão e requisitos imprecisos podem ser difíceis de verificar Meta – Uma intenção geral do utilizador, tal como a facilidade de utilização Requisito não funcional verificável – Uma declaração recorrendo a uma medida que pode ser objectivamente testada As metas são úteis para os desenvolvedores, uma vez que exprimem as intenções dos utilizadores do sistema 2009/2010 20 Engenharia do Software I

30. Exemplos Meta “O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de modo a minimizar erros do utilizador.” Requisito não funcional verificável “Controladores experientes devem ser capazes de usar todas as funcionalidades do sistema após duas horas de treino. Após este treino, o número médio de erros cometidos por utilizadores experientes não pode exceder dois erros diários.” 2009/2010 21 Engenharia do Software I

31. Medidas de requisitos 2009/2010 22 Engenharia do Software I

32. Interacção entre requisitos Em sistemas complexos é comum haver conflitos entre requisitos não funcionais Sistema espacial Para minimizar o peso é necessário minimizar o número de circuitos integrados separados do sistema Para minimizar o consumo devem usar-se circuitos integrados de baixo consumo No entanto, usar circuitos de baixo consumo pode implicar ter de usar um maior número de circuitos. Qual é o requisito mais crítico? 2009/2010 23 Engenharia do Software I

33. Requisitos do domínio Derivam do domínio da aplicação e descrevem características do sistema que reflectem esse domínio Podem ser novos requisitos funcionais, restrições a requisitos existentes ou definir computações específicas Se não forem satisfeitos, o sistema pode não ser realizável 2009/2010 24 Engenharia do Software I

34. Requisitos de domínio do LIBSYS “Devido a restrições quanto a direitos de autor, alguns documentos têm de ser eliminados logo que cheguem. Dependendo dos requisitos do utilizador, estes documentos serão impressos localmente no servidor do sistema para envio manual ao utilizador ou encaminhados para uma impressora de rede.” 2009/2010 25 Engenharia do Software I

35. Problemas com requisitos de domínio Compreensíveis? Requisitos expressos na linguagem do domínio da aplicação Muitas vezes os engenheiros de software que desenvolvem o sistema não os compreendem Explícitos? Especialistas do domínio conhecem-no tão bem que nem pensam em tornar explícitos os requisitos do domínio 2009/2010 26 Engenharia do Software I

36. Requisitos do utilizador Devem descrever requisitos funcionais e não funcionais de tal modo que sejam compreensíveis por utilizadores do sistema que não tenham conhecimento técnico pormenorizado Definidos usando linguagem natural, tabelas e diagramas que possam ser compreendidos por todos os utilizadores 2009/2010 27 Engenharia do Software I

37. Cães e sapatos “Dogsmustbecarried” “Shoesmustbeworn” 2009/2010 28 Engenharia do Software I

38. Problemas da linguagem natural Falta de clareza – É difícil ser preciso sem tornar o documento difícil de ler Confusão – Requisitos funcionais e não funcionais tendem a ser confundidos Amálgama – Diferentes requisitos podem ser expressos em conjunto 2009/2010 29 Engenharia do Software I

39. Requisito do LIBSYS “O LIBSYS fornecerá um sistema contabilístico que manterá registos de todos os pagamentos efectuados pelos utilizadores do sistema. Os gestores do sistema poderão configurar este sistema de modo a que utilizadores regulares possam ser beneficiados com preços especiais.” 2009/2010 30 Engenharia do Software I

40. Linhas de orientação para a redacção de requisitos Escolha um formato padrão e use-o para todos os requisitos Use a língua de uma forma consistente. Use o futuro (shall) para todos os requisitos obrigatórios e “é desejável” (should) para todos os requisitos desejáveis Enfatize as partes cruciais do requisito Evite usar calão informático 2009/2010 31 Engenharia do Software I

41. Requisitos de sistema Especificações mais pormenorizadas do que as dos requisitos do utilizador das funções, serviços e restrições do sistema Pretende-se que sirvam de base para o desenho do sistema Podem ser incorporadas no contrato do sistema 2009/2010 32 Engenharia do Software I

42. Requisitos e desenho Em princípio Requisitos declararam o que o sistema deve fazer Desenho descreve como o sistema o faz Na prática são inseparáveis Pode desenhar-se uma arquitectura do sistema para estruturar os requisitos Sistema poder interoperar com outros sistemas que geram requisitos de desenho A utilização de um desenho específico pode ser um requisito do domínio 2009/2010 33 Engenharia do Software I

43. Alternativas à especificação em linguagem natural 2009/2010 34 Engenharia do Software I

44. Especificações em linguagem estruturada Liberdade do redactor dos requisitos limitada por modelo pré-definido para definir requisitos Requisitos escritos de forma normalizada Terminologia usada na descrição pode ser limitada Mantém-se quase intacta expressividade da língua natural mas impõe-se alguma uniformidade nas especificações 2009/2010 35 Engenharia do Software I

45. Especificações baseadas em modelos Estrutura Definição da função ou entidade Descrição de entradas e sua origem Descrição de saídas e seu destino Indicação de outras entidades requeridas Pré e pós-condições (se apropriado) Efeitos laterais da função (se houver) 2009/2010 36 Engenharia do Software I

46. Um exemplo 2009/2010 37 Engenharia do Software I

47. Especificação tabular Usada como suplemento à língua natural Particularmente útil quando é necessário definir vários possíveis cursos de acção 2009/2010 38 Engenharia do Software I

48. Um exemplo 2009/2010 39 Engenharia do Software I

49. Modelos gráficos Para mostrar mudanças de estado Para descrever uma sequência de acções 2009/2010 40 Engenharia do Software I

50. Diagramas de sequência Mostram sequência de eventos durante interacção de utilizador com sistema Tempo decorre de cima para baixo Levantamento de dinheiro de um ATM Validar cartão Lidar com o pedido Completar a transacção 2009/2010 Engenharia do Software I 41

51. Diagrama de sequência de um levantamento de ATM 2009/2010 Engenharia do Software I 42

52. Especificação de interfaces Maioria dos sistemas operam com outros sistemas Especificação de interfaces entre sistemas é parte dos requisitos Pode ser necessário definir interfaces de três tipos Procedimentais Estruturas de dados trocadas Representação de dados Notações formais são técnica eficaz de especificar interfaces 2009/2010 Engenharia do Software I 43

53. Exemplo /* * Defines an abstract printer server. *Requires: interfaces Printer and PrintDocument * Provides: initialize, print, displayPrintQueue, * cancelPrintJob, switchPrinter */ interface PrintServer { void initialize(Printer printer); void print(Printer printer, PrintDocument document); void displayPrintQueue(Printer printer); void cancelPrintJob(Printer printer, PrintDocument document); void switchPrinter(Printer printer1, Printer printer2, PrintDocument document); } 2009/2010 Engenharia do Software I 44

54. Documento de requisitos Declaração oficial daquilo que se requer dos desenvolvedores do sistema Deve incluir Definição dos requisitos de utilizador Especificação dos requisitos do sistema Não é um documento de desenho Afirma o que o sistema deve fazer… …e não como o deve fazer 2009/2010 Engenharia do Software I 45

55. Utilizadores do documento de requisitos 2009/2010 Engenharia do Software I 46

56. A reter Requisitos – Declaram o que o sistema deve fazer e definem restrições à sua operação e implementação Requisitos funcionais – Declaram os serviços que o sistema deve fornecer Requisitos não funcionais – Restringem o sistema em desenvolvimento ou o processo de desenvolvimento 2009/2010 Engenharia do Software I 47

57. A reter Requisitos do utilizador – Declarações de alto nível acerca do que o sistema deve fazer. Expressos usando linguagem natural, tabelas e diagramas. Requisitos do sistema – Destinam-se a comunicar as funções que o sistema deve fornecer Documento de requisitos – Declaração dos requisitos do sistema acordada entre as partes 2009/2010 Engenharia do Software I 48

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