Engenharia de Requisitos 1 - Introdução

Transcrição

1 Engenharia de Requisitos 1 - Introdução Pedro Campos Professor Auxiliar, Universidade da Madeira - pcampos@uma.pt 1

2 Agenda Apresentação Equipa docente Definição de ER Bibliografia Objectivos da disciplina Programa da disciplina Conceitos introdutórios de ER 2

3 Definição de Engenharia de Requisitos A engenharia de requisitos (ER) é um conjunto de actividades dedicadas à identificação e comunicação do propósito de um sistema de software, bem como o contexto no qual ele será utilizado. A ER actua como uma ponte entre: as necessidades do mundo real dos utilizadores, clientes e outros constituintes afectados por um sistema de software, e as capacidades e oportunidades oferecidas pelas tecnologias de software. ER não é uma fase nem uma etapa! A comunicação é tão importante como a análise! ER é sobre o que é preciso e sobre o que é possível! 3

4 Bibliografia 4

5 Objectivos da disciplina Examinar o estado da arte em investigação e prática de ER O papel da ER na engenharia de software actual Técnicas, notações, métodos, processos e ferramentas de ER Obter experiência prática em técnicas de ER seleccionadas Compreender a natureza essencial da ER Multi-disciplinar, intensiva em comunicação oral e escrita Factores contextuais Obter fundamentos para investigação em ER Metodologias actuais Literatura Casos práticos e problemas em aberto 5

6 Programa resumido Introdução à Engenharia de Requisitos Contexto e Fundamentos Iniciando um Projecto Técnicas de Elicitação de Requisitos Técnicas de Modelação de Requisitos Modelação de Negócios Modelação de Qualidade Modelação de Informação e Comportamento Especificações e Validação Gestão da Mudança Formalidade 6

7 O que são requisitos? Dois princípios básicos: É útil separar o problema da solução...e documentar o problema separadamente da solução Esta separação, na prática, nunca consegue ser atingida na totalidade...porque o design muda o mundo, logo muda também o problema! Porque é que a ER é importante? Porque o falhanço sai caro, muito caro! Domínios de aplicação ER é sobre o estudo das actividades humanas, muito mais do que sobre computadores e informática! 7

8 Separar o problema da solução Situação do problema Correspondência Correcção Enunciado do problema Enunciado da implementação Verificação Validação Sistema 8

9 ...Mas o design altera o mundo Mudança Situação do problema Sistema Enunciado da implementação Modelo abstracto do mundo Enunciado do problema 9

10 Separar o problema da solução Uma descrição separada é útil porque: O problema mais óbvio pode não ser o problema a atacar O enunciado do problema deve ser discutido com os stakeholders O enunciado do problema pode ser usado para avaliar decisões de design O enunciado do problema é uma boa fonte para casos de teste Mas é necessário verificar outros itens: A solução resolve correctamente o problema enunciado O enunciado do problema corresponde às necessidades dos stakeholders 10

11 Sobre a ER ER não é necessariamente um processo sequencial ER é um conjunto de actividades ao longo de todo o desenvolvimento O enunciado do problema será imperfeito Os modelos de ER são aproximações ao mundo real Aperfeiçoar uma especificação pode custar muito $$$ A análise de requisitos tem um custo Para diferentes projectos, o rácio custo-benefício será diferente O enunciado do problema nunca deve ser tido como fixo A mudança é inevitável, logo deve ser antevista e planeada Deve haver uma forma de incorporar mudanças periodicamente 11

12 Importância da ER Chaos Report, Standish Group, 1995 O pai de todos os relatórios sobre falhanços de projectos de software 31,1% dos projectos são cancelados antes de terminarem 52,7% dos projectos custam mais 189% do que a estimativa inicial Apenas 16% dos projectos são completados a tempo e dentro do orçamento Porquê? Requisitos incompletos (13.1%) Falta de envolvimento com o utilizador (12.4%) Falta de recursos (10.6%) Expectativas irrealistas (9.9%) Falta de suporte executivo (9.3%) Alterações aos requisitos e especificações (8.7%) Falta de planeamento (8.1%) Sistema deixou de ser necessário (7.5%) 12

13 Que fazem os engenheiros de requisitos? Existe a noção de que há um PROBLEMA a ser resolvido Insatisfação com sistema actual, nova oportunidade de negócio, etc. Um engenheiro de requisitos é um agente de mudança! O engenheiro de requisitos deve: Tornar-se um perito no domínio da aplicação Identificar o problema e a oportunidade: Qual o problema a ser resolvido? (Identificar a Fronteira do problema) Onde está o problema? (Compreender o Domínio do problema e o Contexto) De quem é o problema? (Identificar os Stakeholders) Porque necessita ser resolvido? (Identificar os Objectivos dos stakeholders) Como poderia um sistema de software ajudar? (Definir Cenários) Quando necessita ser resolvido? (Identificar Restrições ao desenvolvimento) O que nos pode impedir de o resolver? (Identificar Riscos) 13

14 Processos, métodos e ferramentas Notação Esquema de representação (ou linguagem) para exprimir conceitos Técnica Exº: Z, lógica de 1ª ordem, diagramas de fluxo de dados, UML,... Descreve como realizar uma actividade técnica particular e, se necessário, como descrever um produto dessa actividade numa dada notação Método Exº: Diagramas de casos de utilização Descrição técnica sobre como realizar uma colecção de actividades, focando-se na integração de técnicas e guias sobre o seu uso Exº: OMT, RUP, KAOS,... Modelo de processo Descrição abstracta de como conduzir uma colecção de actividades, focando-se na utilização de recursos e dependências entre actividades Processo Actuação de um modelo de processo 14

15 Métodos e Processos em ER Onde encaixar os métodos de ER nos processos de ER? Muitas vezes não é claro onde cada método encaixa Cada método é apropriado para alguns tipos de domínio de problema Os métodos variam na sua cobertura (de actividades de ER) e no foco, por exº: Cobertura: Elicitação, Modelação, Análise, etc. Foco: Objectivos, Comportamentos, Pontos de vista 15

16 Temas chave da disciplina Sistemas de Software (intensivos) Mudança contínua Desenvolvimento centrado nos humanos Uma perspectiva de sistemas Abordagem multi-disciplinar Gestão do Risco... Contínua! Design como reflexão Muitos pontos de vista ER como uma disciplina de negociação 16