Análise e Projeto Orientado a Objetos

Transcrição

1 Análise e Projeto Orientado a Objetos Aula Engenharia de Requisitos Bruno Neiva Moreno Instituto Federal do Rio Grande do Norte Campus Nova Cruz bruno.moreno@ifrn.edu.br 1/27

2 Introdução A Engenharia de Requisitos tenta resolver, talvez, um dos maiores problemas da indústria de software; Está relacionada com: Definição do que o sistema deve fazer; Propriedades emergentes desejáveis e essenciais; Restrições quanto à operação do sistema; Restrições quanto aos processos de desenvolvimento. Um dos artefatos produzidos pelos processos de Engenharia de Requisitos é o documento de requisitos: É uma declaração oficial do que os desenvolvedores devem implementar. 2/27

3 Introdução A Engenharia de Requisitos pode ser pensada como o processo de comunicação entre os clientes, usuários e desenvolvedores. 3/27

4 Requisitos de Software São descrições dos serviços fornecidos pelo sistema e suas restrições operacionais; Os requisitos refletem o que o sistema deve fazer para resolver algum problema do cliente. 4/27

5 Requisitos de Software A Engenharia de Requisitos envolve o processo de descobrir, analisar, documentar e verificar serviços e restrições; Existem diferentes formas de expressar requisitos: Isso ocorre porque o termo requisito não é usado de maneira consistente na indústria de software: Pode ser uma simples declaração de alto nível; Pode ser uma declaração formal e detalhada. 5/27

6 Requisitos de Software Os requisitos podem ser classificados em diferentes níveis de abstração: Requisitos de usuário: declarações, em alto nível, dos serviços esperados pelo sistema e suas restrições; Requisitos de sistema: definem, detalhadamente, as funções, serviços e restrições operacionais do sistema. Na prática, requisitos de usuário e de sistema são formas diferentes de se representar requisitos. 6/27

7 Tipos de Requisitos Requisitos Funcionais: São declarações de serviços que o sistema deve fornecer; Define como o sistema deve reagir à entradas específicas e como deve se comportar em diferentes situações. Requisitos Não-Funcionais: São restrições sobre os serviços oferecidos pelo sistema; Requisitos de Domínio: São requisitos provenientes do domínio da aplicação; Refletem as características e restrições do domínio Podem ser funcionais ou não funcionais. 7/27

8 Requisitos Funcionais Expressam exatamente o que o sistema deve fazer; Exemplo (Sistema de Biblioteca): O usuário deve ser capaz de fazer uma busca por livros em toda a biblioteca ou apenas em seções da biblioteca Qual o nível de abstração dessa descrição de requisito? É um requisito de usuário ou de sistema? Para cada pedido, deve ser alocado um identificador único (OR- DER ID) Qual o nível de abstração dessa descrição de requisito? É um requisito de usuário ou de sistema? 8/27

9 Requisitos Funcionais A especificação de requisitos funcionais deve ser completa e consistente: Todos os serviços devem ser definidos; Os requisitos não devem ser contraditórios. Em alguns casos, os RFs também estabelecem explicitamente o que o sistemas não deve fazer. 9/27

10 Requisitos Não-Funcionais São aqueles requisitos que não estão diretamente ligados a funções específicas do sistema; Podem estar relacionados às propriedades emergentes: Confiabilidade; Tempo de Resposta; Espaço de Armazenamento. Podem definir restrições e as representações de dados usadas nas interfaces do sistema. 10/27

11 Requisitos Não-Funcionais Podem especificar desempenho, proteção, disponibilidade e outras propriedades emergentes do sistema; São geralmente mais importantes do que os requisitos funcionais do sistema. A não implementação de um requisito funcional pode ser contornada por um usuários, por outro lado, a de um requisito não funcional, compromete o sistema como um todo. 11/27

12 Requisitos Não-Funcionais Requisitos não funcionais não estão relacionados apenas com o sistema a ser desenvolvido: Podem estabelecer restrições quanto ao processo, e.g.: Definição de quais padrões de qualidade serão utilizados; Especificação das ferramentas a serem utilizadas; Definição do processo de desenvolvimento. 12/27

13 Requisitos Não-Funcionais Os RNFs existem devido a diferentes motivos: Necessidades do usuário; Restrições do orçamento; Poĺıticas organizacionais; Interoperabilidade entre sistemas ou hardwares; Fatores externos à organização: regulamentos, legislação, etc. 13/27

14 Tipos de Requisitos Não-Funcionais 14/27

15 Tipos de Requisitos Não-Funcionais 15/27

16 Tipos de Requisitos Não-Funcionais 16/27

17 Tipos de Requisitos Não-Funcionais 17/27

18 Tipos de Requisitos Não-Funcionais 18/27

19 Requisitos Não-Funcionais Um problema comum dos RNFs é que eles podem ser difíceis de serem verificados; São definidos como metas gerais (e.g. usabilidade, capacidade de recuperação a falhas, etc) A verificação dos RNFs pode depender da interpretação dos desenvolvedores Sempre que possível, devem ser descritos quantitativamente para posterior teste objetivo; 19/27

20 Requisitos Não-Funcionais Requisito de Produto: 8.1: A interface de usuário deve ser implementada como simples HTML, sem frames ou applets de Java. Requisito Organizacional: 8.2: O processo de desenvolvimento do sistema e os documentos a serem entregues devem estar em conformidade com o processo e produtos definidos pelo padrão XYZ. Requisito Externo: 8.3: O sistema não deve revelar quaisquer informações pessoais sobre os usuários do sistema ao pessoal da biblioteca que usa o sistema, com exceção do nome e número de matrícula. 20/27

21 Requisitos Não-Funcionais Meta do Sistema: 8.4: O sistema deve ser fácil de ser usado pelos controladores experientes e ser organizado de modo que os erros dos usuários sejam minimizados Requisito Não-Funcional Verificável: Os controladores experientes devem ser capazes de usar todas as funções do sistema depois de um treinamento no total de duas horas. Após esse treinamento, o número médio de erros cometidos pelos usuários experientes não deve exceder dois por dia. 21/27

22 Requisitos de Domínio São derivados do domínio da aplicação do sistema; Podem ser novos requisitos funcionais ou restringir requisitos funcionais existentes, e.g.: Definição de cálculos específicos que devem ser realizados; Implementação de legislações vigentes; Implementação de regulamentos organizacionais. 22/27

23 A distinção entre diferentes tipos de requisitos não é tão clara. 23/27

24 Diferenças de Requisitos Requisito relacionado à segurança de informação parece ser não funcional: Ao detalhá-lo, percebe-se que é um requisito funcional; Pode ser implementado pela autenticação do usuário; Pode-se definir diferentes papéis de usuários; Pode-se atribuir diferentes tarefas aos papéis. Essa dificuldade é uma das razões pelas quais foram criados outros sistemas de classificação de requisitos. 24/27

25 FURPS+ É um sistema de classificação de requisitos que representa o acrônimo a seguir: Funcionalidade (Functionality): características, serviços; Usabilidade (Usability - UX ): fatores humanos, recursos de ajuda, documentação, manual do usuário; Confiabilidade (Reliability): frequência de falhas, capacidade de recuperação, previsibilidade; Desempenho (Perfomance): tempos de resposta, etc.; Suportabilidade (Supportability): facilidade de adaptação e de manutenção, internacionalização, etc. 25/27

26 FURPS+ O + indica aspectos auxiliares e subfatores, tais como: Implementação: limitações de recursos, linguagens e ferramentas, hardwares, etc; Interface: restrições impostas pelas interfaces com sistemas externos; Operações: gerenciamento do sistema no ambiente operacional; Empacotamento: por exemplo, uma caixa física; Questões legais: licenças de uso, etc. 26/27

27 Atividade Prática Reúnam-se em grupo para: Definir, pelo menos, três requisitos não funcionais; Façam um levantamento dos riscos; Preparar protótipos que possam auxiliar na validação de ideias e provas de conceitos. 27/27