Engenharia de Requisitos. Sumário

Transcrição

1 QJHQKDULDGH6RIWZDUH Engenharia de Requisitos Carla Ferreira Sumário Caracterização Objectivos Problemas Qualidades Factores Não-Técnicos Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Engenharia de Requisitos 2 1

2 Objectivos Identificação de quais são as características do sistema a desenvolver Assegurar que essas características correspondem aos objectivos do negócio Verificar se o sistema desenvolvido satisfaz ou não as características identificadas Engenharia de Requisitos 3 Definição de Requisito Um UHTXLVLWR é uma característica do sistema, ou a descrição de algo que o sistema é capaz de fazer para satisfazer os seus objectivos Em princípio os requisitos devem versar sobre o espaço do problema, RTXr, e não sobre o espaço da solução, R FRPR, contudo pode acontecer que os requisitos coloquem restrições ao espaço da solução Engenharia de Requisitos 4 2

3 Tipos de Requisitos Os UHTXLVLWRVIXQFLRQDLV descrevem uma interacção entre o sistema e o seu ambiente Os UHTXLVLWRVQmRIXQFLRQDLV descrevem restrições ao sistema que limitam as possibilidades de implementação. Têm impacto no desenho Os UHTXLVLWRVGRGHVHQYROYLPHQWR descrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores Engenharia de Requisitos 5 Requisitos Funcionais Contexto do sistema Reacção a estímulos externos Estados do sistema Informação manipulada pelo sistema... Engenharia de Requisitos 6 3

4 Requisitos Não-Funcionais Usabilidade Desempenho Segurança Robustez Fiabilidade Disponibilidade Portabilidade Tecnologia de implementação Ambiente físico da instalação... Engenharia de Requisitos 7 Requisitos de Desenvolvimento Manutenção Evolução Documentação Processo Orçamento Recursos humanos Recursos computacionais... Engenharia de Requisitos 8 4

5 Actividades 1. Estudo de viabilidade o sistema faz sentido do ponto de vista do negócio e é realizável com o orçamento disponível 2. Análise de requisitos entender como vai ser o sistema analisando diversas fontes 3. Definição de requisitos descrever os requisitos de modo a serem entendido pelos utilizadores e clientes 4. Especificação de requisitos descrever detalhadamente os requisitos de modo a permitir fazer a ponte com a solução Engenharia de Requisitos 9 Análise de Requisitos Fontes dos Requisitos Clientes e utilizadores Organização e outros sistemas existentes Documentação existente Matriz de tipos de requisitos Reutilização de requisitos Modelos do domínio Modelo do sistema actual Engenharia de Requisitos 10 5

6 Análise de Requisitos Identificar as pessoas, os processos e os recursos envolvidos no problema e documentar as suas relações Identificar a fronteira do sistema Separar os requisitos em três categorias: Têm que ser satisfeitos É desejável que sejam satisfeitos Podem ser satisfeitos mas é possível eliminar Engenharia de Requisitos 11 Documentos de Requisitos HILQLomRGH5HTXLVLWRV contém uma lista de tudo o que o cliente espera que o sistema faça. Define um entendimento entre o cliente e a equipa de desenvolvimento sobre o que é que o sistema deve fazer. É escrito pelos clientes e os analistas de requisitos. VSHFLILFDomRGH5HTXLVLWRV rescreve o documento de definição de requisitos em termos técnicos mais apropriados à equipa de desenvolvimento e às actividades de desenho. É escrito pelos analistas de requisitos. Engenharia de Requisitos 12 6

7 Problemas dos Requisitos Linguagem natural é inevitável no levantamento de requisitos Dificuldades comunicação entre os utilizadores e a equipa de desenvolvimento Os utilizadores não concordam sobre os requisitos Por vezes não é possível definir completamente o problema Os requisitos evoluem durante o processo desenvolvimento O levantamento de requisitos origina problemas de equilíbrio de poder A descrição do problema é influenciada pela solução Engenharia de Requisitos 13 Qualidades dos Requisitos &RHUrQFLD não devem ser ambíguos ou incoerentes &RPSOHWXGH todos os estados possíveis, alterações de estados, entradas, etc, devem ser descritos Externamente Completos todas as ligações com o ambiente desejadas pelo cliente estão descritas Internamente Completos não existem referências indefinidas entre requisitos 5HDOLVPR o que é pedido pelo cliente deve ser realizável Engenharia de Requisitos 14 7

8 Qualidades dos Requisitos &ODUH]D a descrição dos requisitos deve ser simples e clara para os utilizadores 9DOLGDGH o requisito deve descrever algo que é de facto relativo ao problema &HUWLILFDomR deve ser possível escrever testes que demonstram que o requisito foi satisfeito 5DVWUHDELOLGDGH deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito Engenharia de Requisitos 15 Certificação de Requisitos Os requisitos devem ser escritos de uma forma que permita a sua verificação objectiva. Para isso devem seguir-se as seguintes regras: Escrever uma quantidade para cada advérbio e adjectivo de modo a que o significado dos qualificadores seja claro e não ambíguo Substituir pronomes por nomes de entidades Assegurar que cada substantivo é definido exactamente uma única vez nos documentos de requisitos Engenharia de Requisitos 16 8

9 Factores Sociais e Organizacionais O sistema vai levar à redução de gestores intermédios Contudo, os gestores intermédios são uma importante fonte de informação sobre os requisitos do sistema Os utilizadores e a equipa de desenvolvimento não constituem um todo partilhando os mesmos objectivos pelo que vão surgir preconceitos entre os intervenientes Engenharia de Requisitos 17 Intervenientes Existem diferentes intervenientes: Gestores de Processo, definem a calendarização Clientes e Utilizadores, entendem os requisitos Gestores do Negócio, entendem o impacto do sistema no negócio Arquitectos do Sistema, usam os requisitos para a definição da arquitectura Avaliadores do Sistema, recolhem dados para os testes e desenvolvem grupos de testes Os diferentes intervenientes podem ter visões conflituosas sobre os requisitos, e.g., entre o cliente e o utilizador Engenharia de Requisitos 18 9

10 Equipa -> Utilizadores Não sabem o que querem Não são capazes de exprimir o que querem As suas necessidades são políticas Querem as coisas já Não conseguem atribuir prioridades às necessidades Não assumem responsabilidades Não aceitam compromissos... Engenharia de Requisitos 19 Utilizadores -> Equipa Não entendem as necessidades operacionais Dão demasiada importância aos aspectos técnicos Tentam dizer-nos qual deve ser o nosso trabalho Não conseguem implementar requisitos muito claros Estão sempre fora do orçamento Estão sempre atrasados Pedem tarefas aos utilizadores que os desviam da sua tarefa principal... Engenharia de Requisitos 20 10

11 Técnicas Representação de Requisitos Prototipagem Matriz Volere Casos de Uso Figuras Densas Rich Pictures) Engenharia de Requisitos 21 Representação de Requisitos O objectivo das representações de requisitos é: Reduzir a imprecisão associada à linguagem natural Separar a descrição do problema da construção da solução Engenharia de Requisitos 22 11

12 Representações Axiomática Linguagem Dados Abstractos Diagramas de Fluxo de Dados Tabelas de Decisão Diagramas de Transição Baseado em Objectos Engenharia de Requisitos 23 Axiomática Especifica as propriedades básicas do sistema, como axiomas, e como o comportamento gera novas propriedades, os teoremas Exige que o conjunto de axiomas seja completo e coerente Particularmente útil para sistemas peritos Engenharia de Requisitos 24 12

13 Axiomática Exemplo 1) Engenharia de Requisitos 25 Axiomática Exemplo 2) Engenharia de Requisitos 26 13

14 Linguagem Descreve requisitos como cadeias de caracteres de uma linguagem Permite automatizar a verificação da completude e da coerência dos requisitos Particularmente útil no desenvolvimento de compiladores Engenharia de Requisitos 27 Dados Abstractos Descreve o sistema baseado nos dados Permite ignorar como os dados estão implementados e são manipulados Particularmente útil quando o problema não está baseado em funções Engenharia de Requisitos 28 14

15 Diagramas de Fluxo de Dados Representa Processamento de dados Relações de produção e consumo de dados Repositórios de dados Permite ignorar o fluxo de execução Engenharia de Requisitos 29 DFDs - Exemplo User database Library card Check user user details update user details update details Library user requested item issued item User status Check item UserID Item status Issue item ItemID return date Library assistant item details Update details Item database Engenharia de Requisitos 30 15

16 Tabelas de Decisão Representam regras estímulo/resposta quando um conjunto de condições se verifica Engenharia de Requisitos 31 Diagramas de Transição Representam o sistema em termos da sua reacção a eventos internos e externos Permite ignorar a sequência total de execução associada a cada interacção e, desta forma, o comportamento global do sistema Engenharia de Requisitos 32 16

17 Diagramas de Transição Engenharia de Requisitos 33 Baseado em Objectos Estende a abordagem estática dos dados abstractos com os conceitos de: Encapsulação Hierarquia de classes Herança Polimorfismo Facilita a classificação de entidades Engenharia de Requisitos 34 17

18 Baseado em Objectos 1 1 * 1 * " * *! * 1 * " #$ 1 * " % Engenharia de Requisitos 35 Linguagens Formais - Z Engenharia de Requisitos 36 18

19 & Escolher uma Representação É necessário analisar as diferentes técnicas de representação de acordo com os seguintes itens: Implementação: Ajuda na implementação? Testes: Ajuda nos testes? Legibilidade: A especificação é legível para os peritos do domínio? Manutenção: A especificação pode ser útil durante a manutenção? Modularidade: Permite decomposição? Expressividade: Com que facilidade representa as abstracções do problema? Engenharia de Requisitos 37 Escolher uma Representação Correcção: Permite a detecção de incorrecções ou incoerências? Verificação: A especificação é verificável formalmente? Geração: Se possui geração de código este é eficiente? Suporte Computacional: Possui suporte computacional? Incompleta: Suporta informação incompleta? Aprendizagem: Qual é a curva de aprendizagem? Disciplina: Conduz a uma disciplina de escrita de requisitos? Engenharia de Requisitos 38 19

20 Protótipos para Requisitos Os protótipos permitem detalhar e completar a lista de requisitos A prototipagem pode ser aplicada a: Interfaces Validar requisitos funcionais Validar requisitos não funcionais como o desempenho Mostrar, à gestão, da viabilidade da aplicação Desenho... Engenharia de Requisitos 39 Tipos de Protótipos Consideram-se dois tipos de protótipos: Protótipo descartável o principal objectivo é validar ou clarificar os requisitos Protótipo evolutivo adicionalmente ao protótipo descartável também tem como objectivo o desenvolvimento incremental do sistema final Engenharia de Requisitos 40 20

21 Técnicas para Prototipagem Linguagens de especificação executáveis linguagens formais, e.g. Z Linguagens de alto nível linguagens dinâmicas, e.g. Smalltalk Geradores de aplicações geração de código, e.g. SQL Composição de componentes reutilizáveis composição de componentes independentes, e.g. UNIX Shells Engenharia de Requisitos 41 Matriz Volere Estrutura a linguagem natural Enumera requisitos não funcionais tipo Look and feel Usabilidade Desempenho Operacionais Manutenção e portabilidade Segurança Culturais e políticos Legais Engenharia de Requisitos 42 21

22 Matriz Volere Engenharia de Requisitos 43 Matriz Volere Exemplos de medidas para verificação da conformância de requisitos Requisito funcional o resultado de um cálculo é o esperado Desempenho 98% das transacções têm um tempo de resposta inferior a 1,5 segundos Operacionais 90% de um painel de trabalhadores conseguem utilizar o produto numa simulação das condições operacionais Engenharia de Requisitos 44 22

23 Matriz Volere Manutenção cada 10 alterações ao código devem estar operacionais em 3 semanas Segurança o produto deve estar conforme uma determinada norma Legal o departamento jurídico deve certificar que o produto está de acordo com a legislação Look and feel está de acordo com uma norma Engenharia de Requisitos 45 Casos de Uso Os casos de uso descrevem o sistema do ponto de vista do utilizador. As vantagens são: Delimitam o sistema Cada caso de uso pode ser isolado dos restantes pelo que facilita a decomposição do espaço do problema Podem ser usados para estimar o tempo e o esforço necessário ao desenho e codificação do sistema O desenvolvimento do sistema pode ser seguido em termos dos seus casos de uso Engenharia de Requisitos 46 23

24 Casos de Uso BANCO Levantar Dinheiro <<include>> Depositar Dinheiro <<include>> Autenticação Cliente do Banco <<include>> Transferir Dinheiro entre Contas Engenharia de Requisitos 47 Figuras Densas Permitem fazer uma análise do negócio ao nível de abstracção dos clientes e utilizadores Registar e raciocinar sobre o contexto do trabalho e a forma como este influência o desenho Início da ponte entre o negócio e os requisitos Técnica que facilita a interacção e a comunicação entre os clientes e a equipa Engenharia de Requisitos 48 24

25 Figuras Densas Consideram os seguintes elementos Estrutura refere os aspectos do contexto do trabalho que vão ser alterados Processo refere as transformações que ocorrem no processo de trabalho Objectivos refere as motivações de cada um dos intervenientes Devem-se captar as tensões entre os intervenientes Engenharia de Requisitos 49 Figuras Densas Engenharia de Requisitos 50 25

26 Validação de Requisitos Requirements document Organisational knowledge Organisational standards Requirements validation List of problems Agreed actions Engenharia de Requisitos 51 Validação de Requisitos A validação de requisitos é o processo que determina se a especificação de requisitos é coerente com a definição de requisitos, ou seja, se os requisitos satisfazem as necessidades dos clientes: Cada especificação está relacionada com um requisito no documento de definição de requisitos Cada requisito está tratado no documento de especificação de requisitos Engenharia de Requisitos 52 26

27 Técnicas de Validação Técnicas manuais Leitura Cruzamento de informação Entrevistas Revisões Listas de verificação Cenários Demonstração matemática Engenharia de Requisitos 53 Técnicas de Validação Técnicas automáticas são possíveis se os requisitos estiverem representados de modo a poderem ser tratados computacionalmente bases de dados, linguagens formais, protótipos Cruzamento de informação Prototipagem Simulação Demonstração matemática Engenharia de Requisitos 54 27

28 & Revisão de Requisitos Plan review Distribute documents Prepare for review Hold review meeting Follow-up actions Revise document Engenharia de Requisitos 55 Revisão de Requisitos Juntar representantes da equipa de desenvolvimento, do cliente e dos utilizadores para: Rever objectivos do sistema Comparar os requisitos com os objectivos para confirmar se são todos necessários Verificar a completude e correcção dos requisitos Se foram identificados riscos avaliar com o cliente se a abordagem de solução proposta é a melhor Definir como é que a satisfação de requisitos vai ser verificada durante o desenvolvimento Engenharia de Requisitos 56 28

29 & Métricas para Requisitos Desempenho transacções processadas por segundo, tempo de resposta a um pedido do utilizador, tempo de refrescar o ecrã ) Usabilidade tempo de treino, número de menus de ajuda ) Robustez tempo de recomeçar após faltas ) Portabilidade número de sistemas alvo, número de comandos dependentes do alvo ) Tempo de desenvolvimento uma função do número de requisitos dá uma estimativa do esforço de desenvolvimento, e.g., COCOMO Engenharia de Requisitos 57 Métricas para Requisitos ) Impacto qual o impacto que a alteração de um particular tipo de requisitos tem no sistema ) Complexidade qual a complexidade associada à implementação dos requisitos. Para isso pode-se perguntar aos arquitectos e avaliadores sobre cada requisito: * Conhecido * Novo mas parecido * Novo mas será possível encontrar uma solução * Não se entende e não se sabe se será possível encontrar uma solução * Não se entende e não é possível encontrar uma solução Engenharia de Requisitos 58 29

30 Casos Notáveis Padrões de Interacção com o Cliente Linda Rising Customer Interaction Patterns In Harrison2000. Capítulo 26. Um Processo de Análise de Requisitos para Desenvolvimento com Objectos Bruce Whitenack RAPPeL: A Requirements Analysis Process Pattern Language for Object Oriented Development + Engenharia de Requisitos 59 30