Sumário. Engenharia de Requisitos. Definição de Requisito. Objectivos. Engenharia de Software. Caracterização Objectivos Problemas Qualidades

Transcrição

1 Engenharia de Software Engenharia de Requisitos António Rito Silva 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 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 Definição de Requisito Um requisito é 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, o quê, e não sobre o espaço da solução, o como, contudo pode acontecer que os requisitos coloquem restrições ao espaço da solução Engenharia de Requisitos 3 Engenharia de Requisitos 4

2 Tipos de Requisitos Os requisitos funcionais descrevem uma interacção entre o sistema e o seu ambiente Os requisitos não-funcionais descrevem restrições ao sistema que limitam as possibilidades de implementação. Têm impacto no desenho Os requisitos do desenvolvimento descrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores Requisitos Funcionais Contexto do sistema Reacção a estímulos externos Estados do sistema Informação manipulada pelo sistema... Engenharia de Requisitos 5 Engenharia de Requisitos 6 Requisitos Não-Funcionais Usabilidade Desempenho Segurança Robustez Fiabilidade Disponibilidade Portabilidade Tecnologia de implementação Ambiente físico da instalação... Requisitos de Desenvolvimento Manutenção Evolução Documentação Processo Orçamento Recursos humanos Recursos computacionais... Engenharia de Requisitos 7 Engenharia de Requisitos 8

3 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 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 9 Engenharia de Requisitos 10 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 Documentos de Requisitos Definição de Requisitos 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. Especificação de Requisitos 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 11 Engenharia de Requisitos 12

4 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 Coerência não devem ser ambíguos ou incoerentes Completude 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 Realismo o que é pedido pelo cliente deve ser realizável Engenharia de Requisitos 14 Qualidades dos Requisitos Clareza a descrição dos requisitos deve ser simples e clara para os utilizadores Validade o requisito deve descrever algo que é de facto relativo ao problema Certificação deve ser possível escrever testes que demonstram que o requisito foi satisfeito Rastreabilidade deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito 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 15 Engenharia de Requisitos 16

5 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 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 17 Engenharia de Requisitos 18 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... 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 19 Engenharia de Requisitos 20

6 Técnicas Representação de Requisitos Prototipagem Matriz Volere Casos de Uso Figuras Densas (Rich Pictures) 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 21 Engenharia de Requisitos 22 Representações Axiomática Linguagem Dados Abstractos Diagramas de Fluxo de Dados Tabelas de Decisão Diagramas de Transição Baseado em Objectos 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 23 Engenharia de Requisitos 24

7 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 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 25 Engenharia de Requisitos 26 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 Tabelas de Decisão Representam regras estímulo/resposta quando um conjunto de condições se verifica Engenharia de Requisitos 27 Engenharia de Requisitos 28

8 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 Diagramas de Transição Engenharia de Requisitos 29 Engenharia de Requisitos 30 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 Baseado em Objectos 1 Unidade 1 * Orgão 1 * Função * * Vínculo * Pessoa 1 * FunçãoPrimaria 1 * Cargo FunçãoInerente Discente Docente Funcionario Engenharia de Requisitos 31 Engenharia de Requisitos 32

9 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? 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 33 Engenharia de Requisitos 34 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... 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 35 Engenharia de Requisitos 36

10 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 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 37 Engenharia de Requisitos 38 Matriz Volere 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 39 Engenharia de Requisitos 40

11 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 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 41 Engenharia de Requisitos 42 Cenários Uma sequência de passos que descreve uma interacção entre um utilizador e um sistema O utilizador acede a Agrupamento, onde Agrupamento é o nome do agrupamento. O sistema mostra no ecrã os turnos do agrupamento seleccionado. Para cada turno, são visualizados: O nome do turno; As aulas a ele associadas (dia da semana, hora de início e de fim e sala); O número dos grupos inscritos no turno (quando não tem grupos aparece a mensagem Sem Grupos ). Engenharia de Requisitos 43 Caso de Uso É um conjunto de cenários agrupados de acordo com um objectivo do utilizador Caso de Uso: Visualizar Turnos do Agrupamento Objectivo: Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos. Cenário 1: Existem turnos Cenário 2: Não existem turnos Engenharia de Requisitos 44

12 Actores Um actor é um papel que um utilizador toma em relação com um sistema Humanos Outros sistemas Um utilizador pode ter vários papéis Os actores levam a cabo casos de uso Os actores podem ser facilmente identificados antes da identificação dos casos de uso Os eventos externos facilitam a identificação dos actores Formato Caso de Uso O formato deve ser ajustado às necessidades. Um exemplo de formato: Nome Objectivo Actores Pré-condições Cenário Principal Cenários Alternativos Pós-condições Engenharia de Requisitos 45 Engenharia de Requisitos 46 Visualizar Turnos do Agrupamento Objectivo: Esta funcionalidade permite ao utilizador visualizar, caso existam, os turnos associados ao agrupamento seleccionado e para cada turno o número dos grupos nele inscritos. Actores: Qualquer utilizador do sistema Fénix Pré-Condições: A disciplina seleccionada tem que ter pelo menos um agrupamento. Visualizar Turnos do Agrupamento Cenário Principal: 1. O utilizador acede a Agrupamento, onde Agrupamento é o nome do agrupamento. 2. O sistema mostra no ecrã os turnos do agrupamento seleccionado. 3. Para cada turno, são visualizados: 1. O nome do turno; 2. As aulas a ele associadas (dia da semana, hora de início e de fim e sala); 3. O número dos grupos inscritos no turno (quando não tem grupos aparece a mensagem Sem Grupos ). Engenharia de Requisitos 47 Engenharia de Requisitos 48

13 Visualizar Turnos do Agrupamento Cenário Alternativo: 1. Passo 1 do Cenário Principal. 2. Como não existem turnos do agrupamento seleccionado, o sistema mostra no ecrã a mensagem Não existem turnos. Pós-Condições: O estado do sistema permanece inalterado Diagramas de Casos de Uso Diagrama Casos de Uso - Estudante Inscrever em Grupo <<include>> Remover Inscrição <<include>> Visualizar Grupo do Turno <<include>> Alterar Turno <<include>> Visualizar Turnos do Agrupamento <<include>> Estudante Criar Grupo <<include>> Visualizar Agrupamentos da Disciplina Engenharia de Requisitos 49 Engenharia de Requisitos 50 Relações entre Casos de Uso Inclusão quando nos estamos a repetir em dois os mais casos de uso Generalização uma variação (alternativa) de um comportamento que se pretende representar fora do caso de uso Extensão - uma variação de um comportamento que se pretende representar fora do caso de uso de forma controlada, indicando os pontos de extensão Casos de Uso Revisitados 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 51 Engenharia de Requisitos 52

14 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 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 53 Engenharia de Requisitos 54 Figuras Densas 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 55 Engenharia de Requisitos 56

15 Técnicas de Validação Técnicas manuais Leitura Cruzamento de informação Entrevistas Revisões Listas de verificação Cenários Modelos pré-definidos Demonstração matemática 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 Modelos pré-definidos Prototipagem Simulação Demonstração matemática Engenharia de Requisitos 57 Engenharia de Requisitos 58 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 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 59 Engenharia de Requisitos 60

16 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 61