Engenharia Software I Requisitos

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.

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

Requisitos 2009/2010 3 Engenharia do Software I

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

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

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

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

Leitores dos requisitos ,[object Object]

Arquitectos de sistemaRequisitos do utilizador ,[object Object]

Desenvolvedores de softwareRequisitos do sistema ,[object Object]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Medidas de requisitos 2009/2010 22 Engenharia do Software I

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Um exemplo 2009/2010 37 Engenharia do Software I

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

Um exemplo 2009/2010 39 Engenharia do Software I

Engenharia Software I Requisitos

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Engenharia Software I Requisitos

Similaire à Engenharia Software I Requisitos (20)

Plus de Manuel Menezes de Sequeira

Plus de Manuel Menezes de Sequeira (20)

Dernier

Dernier (20)

Engenharia Software I Requisitos