1.
Engenharia do Software I<br />Manuel Menezes de Sequeira<br />DCTI, ISCTE-IUL<br />Manuel.Sequeira@iscte.pt, D6.02<br />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. <br />

2.
Sumário<br />Requisitos<br />Funcionais e não funcionais<br />Do utilizador<br />Do sistema<br />Especificação da interface<br />Documento de requisitos de software<br />2009/2010<br />2<br />Engenharia do Software I<br />

3.
Requisitos<br />2009/2010<br />3<br />Engenharia do Software I<br />

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

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

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

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

8.
Leitores dos requisitos<br /><ul><li> Gestores de cliente

9.
Utilizadores finais

10.
Engenheiros do cliente

11.
Gestores de contratação

12.
Arquitectos de sistema</li></ul>Requisitos do utilizador<br /><ul><li> Utilizadores finais

13.
Engenheiros do cliente

14.
Arquitectos de sistema

15.
Desenvolvedores de software</li></ul>Requisitos do sistema<br /><ul><li> Engenheiros do cliente (talvez)

16.
Arquitectos de sistema

17.
Desenvolvedores de software</li></ul>Especificação do desenho do software<br />2009/2010<br />8<br />Engenharia do Software I<br />

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

19.
Requisitos funcionais e não funcionais<br />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<br />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.<br />Requisitos de domínio – Requisitos com origem no domínio de aplicação do sistema e reflectindo características desse domínio<br />2009/2010<br />10<br />Engenharia do Software I<br />

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

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

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

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

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

25.
Requisitos não funcionais<br />Definem propriedades e restrições do sistema<br />Propriedades – Requisitos de fiabilidade, tempo de resposta, armazenamento, etc.<br />Restrições – Capacidade dos dispositivos de E/S, representações do sistema, etc.<br />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<br />Requisitos não funcionais podem ser mais críticos que requisitos funcionais! Se não forem cumpridos, o sistema é inútil<br />2009/2010<br />16<br />Engenharia do Software I<br />

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

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

28.
Exemplos de requisitos não funcionais<br />Requisito de produto<br />“A interface com o utilizador do LIBSYS será implementada usando HTML simples, sem frames nem applets Java.”<br />Requisito organizacional<br />“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.”<br />Requisito externo<br />“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.”<br />2009/2010<br />19<br />Engenharia do Software I<br />

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

30.
Exemplos<br />Meta<br />“O sistema deve ser fácil de usar por controladores experientes e deve ser organizado de modo a minimizar erros do utilizador.”<br />Requisito não funcional verificável<br />“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.”<br />2009/2010<br />21<br />Engenharia do Software I<br />

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

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

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

34.
Requisitos de domínio do LIBSYS<br />“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.”<br />2009/2010<br />25<br />Engenharia do Software I<br />

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

36.
Requisitos do utilizador<br />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<br />Definidos usando linguagem natural, tabelas e diagramas que possam ser compreendidos por todos os utilizadores<br />2009/2010<br />27<br />Engenharia do Software I<br />

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

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

39.
Requisito do LIBSYS<br />“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.”<br />2009/2010<br />30<br />Engenharia do Software I<br />

40.
Linhas de orientação para a redacção de requisitos<br />Escolha um formato padrão e use-o para todos os requisitos<br />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<br />Enfatize as partes cruciais do requisito<br />Evite usar calão informático<br />2009/2010<br />31<br />Engenharia do Software I<br />

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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