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 IManuel Menezes de SequeiraDCTI, ISCTE-IULManuel.Sequeira@iscte.pt, D6.02As 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árioRequisitosFuncionais e não funcionaisDo utilizadorDo sistemaEspecificação da interfaceDocumento de requisitos de software2009/20102Engenharia do Software I

3. Requisitos2009/20103Engenharia do Software I

4. RequisitosUm projecto de software tem origem numa ideia deUma outra empresaUma entidade estatalUm outro departamentoVocêRequisitosIndicam o que o sistema fará e com que restriçõesParte fundamental da comunicação com o clienteÉ comum integrarem contrato entre as partes!2009/20104Engenharia do Software I

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

6. Tipos de requisitosDo utilizadorAfirmações em língua natural bem como diagramas acerca dos serviços a fornecer pelo sistema e acerca das suas restrições operacionaisRedigido para os clientesDo sistemaDocumento estruturado com descrições pormenorizadas das funções, serviços e restrições operacionais do sistemaDefine o que deve ser implementado de uma forma que lhe permite ser parte de do contrato com o cliente2009/20106Engenharia do Software I

7. Definição e especificação: exemplosDefiniçã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/20107Engenharia do Software I

8. Leitores dos requisitos Gestores de cliente

9. Utilizadores finais

10. Engenheiros do cliente

11. Gestores de contratação

12. Arquitectos de sistemaRequisitos do utilizador Utilizadores finais

13. Engenheiros do cliente

14. Arquitectos de sistema

15. Desenvolvedores de softwareRequisitos do sistema Engenheiros do cliente (talvez)

16. Arquitectos de sistema

17. Desenvolvedores de softwareEspecificação do desenho do software2009/20108Engenharia 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 versaClienteRequisitos do utilizadorClienteRequisitos do sistemaDesenhoSistema em execução2009/20109Engenharia do Software I

19. Requisitos funcionais e não funcionaisRequisitos 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 particularesRequisitos 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ínio2009/201010Engenharia do Software I

20. Requisitos funcionaisDescrevem a funcionalidade ou serviços do sistemaDependem do tipo de software, dos utilizadores espectáveis e do tipo de sistema no qual o software será usadoRequisitos funcionais Requisitos funcionais do utilizador – Podem ser declarações de alto nível acerca do que o sistema deve fazerRequisitos funcionais do sistema – Devem descrever os serviços do sistema em pormenor2009/201011Engenharia do Software I

21. O sistema LIBSYSFornece uma interface única de acesso a um conjunto de bases de dados de artigos em diferentes bibliotecasUtilizadores podem procurar, descarregar e imprimir esses artigos para uso pessoal2009/201012Engenharia 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/201013Engenharia do Software I

23. Imprecisão dos requisitosConsidere-se a expressão “visualizadores apropriados”Intenção do utilizador – Um visualizador especializado para cada tipo específico de documentoInterpretação do desenvolvedor – Um visualizador de texto que mostra o conteúdo do documentoRequisitos ambíguos podem ser interpretados de forma diferente por desenvolvedores e utilizadoresRequisitos imprecisos dão origem a problemas2009/201014Engenharia do Software I

24. Completude e consistência de requisitosPor princípio os requisitos devem ser simultaneamente completos e consistentesCompletude – Devem incluir descrições de todas os mecanismos e funcionalidades requeridosConsistência – Não deve haver qualquer conflito ou contradição na descrição das funcionalidades e mecanismos do sistemaNa prática é impossível produzir um documento de requisitos completo e consistente2009/201015Engenharia do Software I

25. Requisitos não funcionaisDefinem propriedades e restrições do sistemaPropriedades – 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 desenvolvimentoRequisitos não funcionais podem ser mais críticos que requisitos funcionais! Se não forem cumpridos, o sistema é inútil2009/201016Engenharia do Software I

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

27. Tipos de requisitos não funcionaisRequisitos não funcionaisDe produtoOrganizacionaisExternosEficiênciaPortabilidadeInteroperabilidadeÉticosUsabilidadeFiabilidadeLegislativosFornecimentoNormasPrivacidadeSegurançaImplementaçãoDesempenhoEspaço2009/201018Engenharia do Software I

28. Exemplos de requisitos não funcionaisRequisito 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/201019Engenharia do Software I

29. Metas e requisitosRequisitos não funcionais podem ser muito difíceis de especificar com precisão e requisitos imprecisos podem ser difíceis de verificarMeta – Uma intenção geral do utilizador, tal como a facilidade de utilizaçãoRequisito não funcional verificável – Uma declaração recorrendo a uma medida que pode ser objectivamente testadaAs metas são úteis para os desenvolvedores, uma vez que exprimem as intenções dos utilizadores do sistema2009/201020Engenharia do Software I

30. ExemplosMeta“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/201021Engenharia do Software I

31. Medidas de requisitos2009/201022Engenharia do Software I

32. Interacção entre requisitosEm sistemas complexos é comum haver conflitos entre requisitos não funcionaisSistema espacialPara minimizar o peso é necessário minimizar o número de circuitos integrados separados do sistemaPara minimizar o consumo devem usar-se circuitos integrados de baixo consumoNo entanto, usar circuitos de baixo consumo pode implicar ter de usar um maior número de circuitos. Qual é o requisito mais crítico?2009/201023Engenharia do Software I

33. Requisitos do domínioDerivam do domínio da aplicação e descrevem características do sistema que reflectem esse domínioPodem ser novos requisitos funcionais, restrições a requisitos existentes ou definir computações específicasSe não forem satisfeitos, o sistema pode não ser realizável2009/201024Engenharia 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/201025Engenharia do Software I

35. Problemas com requisitos de domínioCompreensíveis?Requisitos expressos na linguagem do domínio da aplicaçãoMuitas vezes os engenheiros de software que desenvolvem o sistema não os compreendemExplícitos?Especialistas do domínio conhecem-no tão bem que nem pensam em tornar explícitos os requisitos do domínio2009/201026Engenharia do Software I

36. Requisitos do utilizadorDevem 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 pormenorizadoDefinidos usando linguagem natural, tabelas e diagramas que possam ser compreendidos por todos os utilizadores2009/201027Engenharia do Software I

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

38. Problemas da linguagem naturalFalta de clareza – É difícil ser preciso sem tornar o documento difícil de lerConfusão – Requisitos funcionais e não funcionais tendem a ser confundidosAmálgama – Diferentes requisitos podem ser expressos em conjunto2009/201029Engenharia 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/201030Engenharia do Software I

40. Linhas de orientação para a redacção de requisitosEscolha um formato padrão e use-o para todos os requisitosUse 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áveisEnfatize as partes cruciais do requisitoEvite usar calão informático2009/201031Engenharia do Software I

41. Requisitos de sistemaEspecificações mais pormenorizadas do que as dos requisitos do utilizador das funções, serviços e restrições do sistemaPretende-se que sirvam de base para o desenho do sistemaPodem ser incorporadas no contrato do sistema2009/201032Engenharia do Software I

42. Requisitos e desenhoEm princípioRequisitos declararam o que o sistema deve fazer Desenho descreve como o sistema o fazNa prática são inseparáveisPode desenhar-se uma arquitectura do sistema para estruturar os requisitosSistema poder interoperar com outros sistemas que geram requisitos de desenhoA utilização de um desenho específico pode ser um requisito do domínio2009/201033Engenharia do Software I

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

44. Especificações em linguagem estruturadaLiberdade do redactor dos requisitos limitada por modelo pré-definido para definir requisitosRequisitos escritos de forma normalizadaTerminologia usada na descrição pode ser limitadaMantém-se quase intacta expressividade da língua natural mas impõe-se alguma uniformidade nas especificações2009/201035Engenharia do Software I

45. Especificações baseadas em modelosEstruturaDefinição da função ou entidadeDescrição de entradas e sua origemDescrição de saídas e seu destinoIndicação de outras entidades requeridasPré e pós-condições (se apropriado)Efeitos laterais da função (se houver)2009/201036Engenharia do Software I

46. Um exemplo2009/201037Engenharia do Software I

47. Especificação tabularUsada como suplemento à língua naturalParticularmente útil quando é necessário definir vários possíveis cursos de acção2009/201038Engenharia do Software I

48. Um exemplo2009/201039Engenharia do Software I