Engenharia de Requisitos

Apresentação em tema: "Engenharia de Requisitos"— Transcrição da apresentação:

1 Engenharia de Requisitos
Silvia Regina Vergilio - UFPR

2 1) Objetivos O escopo do projeto é refinado em detalhe e será produzida uma especialização de requisitos. Objetivos Fornecer traduzida Projeto, dados informação  procedimentos, representações para arquitetura

3 1) Objetivos – Aspecto Fundamental
Comunicação com o Uusário “Eu sei que você acredita ter entendido o que você pensa que eu disse, mas não estou certo se você está ciente de que o que você ouviu não é o que eu queria dizer.” Cliente anônimo.

4 1) Objetivos - Documentos Gerados
Especificação de Requisitos de Software Manual Preliminar do Usuário Plano de Projeto do Software (revisto).

5 2) Requisitos Requisito: condição necessária para a obtenção de certo objetivo ou para o preenchimento de certo fim Requisito de software: requisitos que o produto a ser desenvolvido deve possuir

6 2) Requisitos Requisitos funcionais: funcionalidade, o que o software deve fazer Requisitos não funcionais: confiabilidade (disponibilidade, integridade, segurança), acurácia, desempenho, interface HM, portabilidade, etc. Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade: procedimentos de testes, mudanças prováveis, prioridades de funções, etc.

7 3) Engenharia de Requisitos
Passos: Entendimento do domínio de aplicação Extração de requisitos: classificação e organização Análise/Especificação dos requisitos – modelos Validação – necessidades do usuário Especificação dos requisitos – modelos, representações formais e informais, lg natural. Essas atividades não são lineares (feedback). Requisitos mal entendidos, incompletos etc são as causas mais frequentes de baixa qualidade, atrasos, etc no produto. Vamos ver primeiro as técnicas de extração de requisitos e depois os modelos.

8 3.1) Extração de Requisitos
Processo de transformação das idéias que estão na mente do usuário (entradas) em um documento formal (saída). A saída é a especificação dos requisitos

9 3.1) Extração de Requisitos – Dificuldades
Para conseguir informação pertinente. Para lidar com a complexidade. (Tornar o problema manipulável; detectar omissões, inconsistências ) Para acomodar mudanças. (Coordenar, avaliar impacto; corrigir defeitos sem gerar erros)

10 3.1) Extração de Requisitos – Principais Causas
1. Deficiências na comunicação 2. Técnicas e ferramentas inadequadas 3. Desconsideração de alternativas. É necessário aplicar: -princípios fundamentais -métodos/técnicas sistemáticos

11 3.1) Extração de Requisitos – O Analista
Absorver fatos a partir de fontes conflitantes ou confusas. Entender os ambientes do usuário/cliente. Comunicamos bem na forma verbal e escrita. “ Enxergar a floresta apesar das árvores”

12 3.1) Extração de Requisitos – Tarefas
1. Reconhecimento (identificação do problema ) 2. Avaliação do problema e síntese de soluções gerais + critérios de validação. 3. Representação dos requisitos => software 4. Revisão da especificação reexame do Plano de Projeto de Software.

13 3.1) Extração de Requisitos – Quem participa
desenvolvedor pessoal de apoio e documentação usuários ou potenciais usuários outras fontes de informações: pessoas e documentos A extração de requisitos pode envolver um número > ou < de pessoas dependendo da complexidade e dos objetivos do produto

14 3.1) Extração de Requisitos – Procedimentos Genéricos
Perguntar – identificar o usuário Observar e inferir – comportamento do usuário, inferir suas necessidades Negociar a partir de um conjunto padrão de requisitos Estudar e identificar problemas Supor – se o produto é novo comparar com existentes A extração de requisitos pode envolver um número > ou < de pessoas dependendo da complexidade e dos objetivos do produto

15 3.1) Técnicas de Extração de Requisitos - Entrevistas
Identificar candidatos Preparação para entrevista agendar preparar questões Condução da entrevista A técnica pode depender do tipo do produto formais – modelos conceituais (principios da ES) – o protótipo é um modelo que também é utilizado para refinar requisitos informais – JAD, braimstorming, entrevistas, PIECES Entrevistas – requer habilidade social, habilidade para ouvir e conhecer algumas táticas não é somente perguntar. Candidatos – financiador do projeto, usuário, quem interage com voce, podem ser diferentes preparar questões – importantes e novas surgirão durante a entrevista agendar com antecedência, lembra, objetivo e duração

16 3.1) Técnicas de Extração de Requisitos - Entrevistas
Condução da entrevista apresentação e objetivos esperar respostas incompletas repetir frases do entrevistado com suas próprias palavras perguntas do tipo sim/não – dúvidas não se perder em detalhes o entrevistado precisa ter o contexto a lg do usuário é diferente da sua fazer comentários gerais para extrair respostas reprimidas ou esquecidas há usuários que falam demais e detalhes sem importância. contexto da pergunta.

17 3.1) Técnicas de Extração de Requisitos - Entrevistas
Finalização tempo, resposta à todas as perguntas consolidar informações (5min), agradecimentos Geração de um documento escrito, planejar próximos passos A

18 3.1) Técnicas de Extração de Requisitos - Braimstorming
Técnica para geração de idéias Reuniões entre desenvolvedores e usuários Um líder é necessário Geração e consolidação das idéias Ausência de crítica e julgamento Elimina dificuldades de comunicação Ou tempestade cerebral O líder inicia, gerencia, vê se o número de idéias é suficiente, etc Duas etapas, consolidação: ver o mérito das idéias.

19 3.1) Técnicas de Extração de Requisitos - PIECES
Geralmente é aplicada na análise de produtos já existentes, mas pode ser adaptada Fornece um conjunto de categorias de questões e de problemas para o desenvolvedor extrair os requisitos

20 3.1) Técnicas de Extração de Requisitos - PIECES
Seis categorias: P - desempenho I - informação E - economia C - controle E - eficiência S - serviços P - desempenho - performance – númeor de tarefas executadas e tempo de resposta I - informação fornecida para e pelo sistema E - economia - custo de usar o sistema, relação custo-benefício, reduzir quantidade de recursos C - controle – questões de desempenho e segurança E - eficiência – relação entre os recursos gastos e quantidade de trabalho util (não produzir perda no uso do recurso – por exemplo: coletar o dado mais de uma vez - redundância S - serviços do sw ao usuário ou a outros softwares

21 3.1) Técnicas de Extração de Requisitos - JAD
JAD – Joint Application Design Princípios básicos: dinâmica de grupo uso de técnicas visuais manutenção do processo organizado e racional utilização de documentação padrão Etapas: planejamento e projeto Está baseado na cooperação, entendimento e trabalho em grupo reuniões para formular problemas e explorar soluções.

22 3.1) Técnicas de Extração de Requisitos - JAD
Seis tipos de participantes líder engenheiro de requisitos executor representantes do usuário representantes de produtos de sw especialista Seis tipos de participantes líder – organiza, dirige, inicia engenheiro de requisitos – documentos, especificação executor – alocação de recursos representantes do usuário – quem utiliza ou quer o sw representantes de produtos de sw – pode esclarecer o usuário o porque, conhece o ambiente no qual o sw rodará e tb o usuário especialista – em

23 3.1) Técnicas de Extração de Requisitos - JAD
Sessão Um ou mais Encontros requisitos desenvolvidos e documentados Adaptação Preparar Organizar Equipe e Material Finalização Converte a informação final em um documento

24 3.1) Técnicas de Extração de Requisitos - Prototipação
1. Determinar se o software é um bom candidato Áreas de aplicação : interface, . . . Complexidade : desenvolvimento de muito código inviabiliza a prototipação (particionável) Característica do cliente e gerente 2. Representação Resumida de Requisitos => particionamento . 3. Um projeto rápido ( arquitetura e dados ).

25 3.1) Técnicas de Extração de Requisitos - Prototipação
4. Protótipo é criado e testado. Técnicas de quarta geração Reutilização de Software Ferramentas de Videoconferência Especialização formal + ambientes interativos. 5. Teste pelo usuário - sugestões (+importante). 6. Repetição de 4 e 5 até que todos os requisitos sejam formalizados; ou que o protótipo tenha evoluído.

26 4) Modelos para Especificação
Representam a realidade Ajudam a organização e especificação mas não na extração Utilizam os princípios de abstração e decomposição – lidar com complexidade Existem diferentes tipos de especificação ao longo do desenvolvimento e em vários níveis. Especificação é um processo de respresentação que tem muito a ver com a solução Tipos de especificação – descritiva e operacional

27 4) Especificação pode ser
Especificação dos requisitos – cliente e desenvolvedor Especificação de projeto geral – projetista e implementador Especificação de módulos – programadores que utilizam e implementam os módulos

28 4) Princípios- Especificação
Separar funcionalidade de implementação Deve abranger o sistema do qual o sw é um componente Deve ser operacional (utilizável) Tolerante a incompleteza Consistente Ajudam a verificar e validar a especificação

29 4) Princípios - Especificação
Realista Fracamente acoplada e localizada localizada: para que um único elemento tenha que ser modificado fracamente acoplada: permitir que adições e remoções sejam feitas facilmente A qualidade da especificação depende do nível de formalidade informais – lg naturais semi-formais – não se preocupa com uma sintaxe precisa ( usa-se ao longo do sistema) formal – sintaxe e semântica precisa –requisitos + críticos (consome + tempo, mais caro)

30 4) Modelos para Especificação
Permitem a aplicação dos princípios de ES. Geralmente cobrem três dimensões do sistema dados (que dados ele mantém) funções (o que o sistema faz) comportamento (como ele se comporta – estados e eventos) podem também ser dinâmicos e estáticos. biblioteca função: localiza obra, mantem cadastro de usuários dados: biblioteca – exemplares, livros, usuários como ele se comporta – espera consulta, prepara resposta, etc.

31 5) Diagrama de Fluxo de Dados – Modelo de Função

32 5) Diagrama de Fluxo de Dados – Modelo de Função
O DFD é um modelo que nos permite mostrar como a informação (dados) flui através de um sistema (ou seja, como ela vai sendo transformada ou organizada) são recebidos podem ser armazenados podem fluir de um processo a outro podem ser transferidos para o ambiente externo

33 5) Diagrama de Fluxo de Dados – Modelo de Função
______

34 5) Diagrama de Fluxo de Dados (DFD) - Exemplo
Agente de Viagem Preparação de Bilhete Horário, dia, destino Dados do vôo Bilhete Sistema de Reserva Informação sem vôos Custo Sistema de Cobrança Cliente Conta Diretórios de vôo Dados contábeis Arquivo de Contabilidade

35 5) Diagrama de Fluxo de Dados (DFD) – Como construir
Em primeiro lugar pensamos no sistema como uma caixa preta e identificamos com quem ele interage (recebe e produz informações) as suas entradas e saídas, estabelecendo os limite do sistema Fazemos um diagrama (Nivel 0) chamado diagram fundamental do sistema ( ou diagrama de contexto)

36 5) Diagrama de Fluxo de Dados (DFD) – Como construir
Cada bolha é uma função do sistema, mas podemos decompor o sistema como sub-funções sendo que dados fluem entre funções ou seja são transformados até a saída.

37 5) Diagrama de Fluxo de Dados (DFD) – Como construir
Particionar as funções em sub-funções: uma bolha deve ser particionada por vez rótulos dos fluxos, bolhas e arquivos devem ser significativos a continuidade da informação deve ser mantida

38 5) Diagrama de Fluxo de Dados (DFD) – Como construir
B F x A f4 z B y x z y

39 5) Diagrama de Fluxo de Dados (DFD) – Quando parar
O DFD mostra as transformações de todas as entrada em saídas Os sub-processos não particionados podem ser considerados elementares Cada bolha está conectada corretamente ao resto da rede As conexões foram minimizadas

40 5) Diagrama de Fluxo de Dados (DFD)
O DFD não mostra: descrição dos fluxos nem mecanismos de sincoronização comportamento

41 5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Fluxo de dados que não é contínuo temp - max  temp - medida. Transforma controle ou eventos. Representa eventos. Armazena itens de controle ou eventos.

42 5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Monitora ph Processo de Controle ph no nível desejado Inicia Pára Ativa/Desativa Muda ph ph ativa Controle da Válvula de entrada Mantém ph constante Ativa/Desativa

43 6) Modelo Entidade Relacionamento (MER)
Dados descrevem coisas do mundo real. Itens de dados relacionados devem ser agrupados Ex: nome, endereço, RG são informações do sistema relacionados a uma entidade do mundo real que é o cliente. Ainda podemos ter relacionamentos entre entidades Modelo Semântico, conceitual de dados Representam dados que precisam ser armazenados pelo sistema (repositórios), agrupapemento desses dados, e o relacionamento entre grupos e como eles são utilizados cliente, carro – entidades nome, endereço, RG - atributos de cleinte número do chassi, cor , ano – atributos de carros alugar - relacionamento

44 6) Modelo Entidade Relacionamento (MER)
DER – Diagrama Entidade Relacionamento O MER permite especificar dados do sistema e utiliza uma ferramenta gráfica chamada DER que tem as seguintes notações Ainda tem uma outra característica representada que é a cardinalidade (1:1) (1:m) (m:m)

45 6) Modelo Entidade Relacionamento (MER)
DER – Diagrama Entidade Relacionamento Exemplo Também existem outras notações para cardinalidade. Exercício: desenhe um DER que represente a matrícula de um aluno em n disciplinas de um curso.

46 6) Modelo Entidade Relacionamento (MER)
Existem muitas ferramentas Fácil de entender Não diz como se forma o atributo CIC Não fica claro

47 7) Máquina de Estados Finitos (MEF)
Os modelos de comportamento do sistema devem mostrar estados eventos que alteram esses estados Eventos são condições e ações para se mudar de estado. O MER e DFD não representam aspectos de controle, por ex, como modelar questões relativas a comportamento? Quando uma função deve começar depois de ter todas as entradas possíveis ou depois que uma outra terminou. Diferentes sistemas, diferentes ênfases e importância, dfierentes modelos. Quando a condição é verdadeira, a ação correspondente é ativada ao finalizar uma ação o estado do componente do sistema que está sendo modelado mudou

48 7) Máquina de Estados Finitos (MEF)
Uma MEF é dada por: (S, s0, I, ), S – conjunto finito e não vazio de estados S0S – estado inicial I – conjunto finito de entradas (A (ações) e C (condições)) que podem ser nulas :SxI  S - função de transição de estados

49 7) Máquina de Estados Finitos Diagrama de Estados (DTE)
Uma MEF pode ser representada por um DTE que são representações gráficas úteis para a sua visulização

50 7) Máquina de Estados Finitos Diagrama de Estados (DTE)
Exercício: Fazer um DTE para modelar o uso de uma lãmpada

51 7) Máquina de Estados Finitos Diagrama de Estados (UML)
Exercício: monitora Ph, nem sempre tem um estado final

52 8) Dicionário de Dados (DD)
Repositório de descrições de tudo que é utilizado em um modelo Vantagens: organização, resolução de ambigüidades e inconsistências, documentação, facilidade para relatórios, para alteração, etc Integração com outros modelos – ferramenta automatizada as descrições podem ser formais ou informais Vamos ver exemplo aqui de um DD para um DFD. Ele deve descrever tudo o que está no DFD. Embora o formato do DD vaire de uma ferramenta para outra , a maioria deles contém.

53 8) Dicionário de Dados (DD) Elemento Fluxo de Dados
nome sinônimo origem: referência do processo destino: referência do processo descrição informal formal

54 8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Uma descrição mais formal representa o fluxo com a seguinte notação: = é composto de + seqüência (e) ( ) opcional(pode ou não estarpresente) { } iteração – { }n n repetições [ | ] ou exclusivo * comentários

55 8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Ex1) nome = sobrenome + {int}n0 + primeiro sobrenome = string[30] int = string[60], primeiro = string[30] Ex2) dados_pessoais = nome +endereço + estado civil +(dependentes)

56 8) Dicionário de Dados (DD) Elemento Fluxo de Dados
Ex3) exemplares = {exemplar} exemplar = n_item+estado+nome_titulo n_item = cod_biblioteca+n_exemplar itens elementares de dados: cod_biblioteca = string[2] n_exemplar = inteiro nome_titulo = string[60]

57 8) Dicionário de Dados (DD) Elemento Depósito de Dados
referência descrição fluxos de entrada e saída conteúdo

58 8) Dicionário de Dados (DD) Elemento Processo (Bolhas)
referência descrição fluxos de entrada e saída resumo lógico

59 8) Dicionário de Dados (DD) Elemento Entidade Externa
nome descrição outras informações importantes

60 9) O Modelo de Objetos – Principais Conceitos
Abstração ou conceito do mundo real Encapsulamento de atributos e serviços Na análise – identificamos objetos no domínio do problema No projeto – pensamos em objetos para a solução Ex o objeto cadeira, mesa, etc. Existe uma diferença de definição para linguagens de programação.

61 9) O Modelo de Objetos – Principais Conceitos
Classe Uma coleção ou agrupamento de um ou mais objetos que podem ser descritos com os mesmos objetos e serviços. Ex: os objetos mesa e cadeira, podem ser agrupados na classe mobília Os objetos em uma classe estão sujeitos às mesmas regras e coisas. Ex: a classe mobilia, etc. O agrupamento do objeto em classes facilita a análise é mais fácil, não se precisa detalhar.

62 9) O Modelo de Objetos – Principais Conceitos
Atributo Característica, qualidade de um objeto ou classe. Seus valores servem para diferenciar objetos (Instâncias)

63 9) O Modelo de Objetos – Principais Conceitos
Ocultamento da Informação -Encapsulamento Cada componente do programa deve conter uma única decisão de projeto. A interface definida de forma a revelar o mínimo possível sobre o seu funcionamento interno.

64 9) O Modelo de Objetos – Principais Conceitos
Ocultamento da Informação -Encapsulamento Reduz efeitos colaterais, facilita reuso, manutenção e testes, entendimento, etc. Acessam-se dados de um objeto apenas com métodos do próprio objeto que funcionam como interface para outros objetos.

65 9) O Modelo de Objetos – Principais Conceitos
Associações entre classes e objetos relacionamentos entre as classes que em geral, representam a utilização de serviços e/ou a organização entre as mesmas. devem refletir o domínio do problema Exemplo aluno de graduação realiza matricula em disciplina. Assim como no MER usa-se o conceito de multiplicidade das associações. Algumas associações entre classes de objetos são representadas através de hierarquias dois tipos hierarquia de generalização/especialização ou composição.

66 9) O Modelo de Objetos – Principais Conceitos
Hierarquia Generalização/Especialização mostra generalizações de entidades do mundo real com características comuns e extensões destas características em casos especializados super-classe – mais genérica sub-classe – mais específica abstração de uma ou mais classes em uma classe mais genérica ou separação de uma classe em uma ou mais classes específicas

67 9) O Modelo de Objetos – Principais Conceitos
abstração de uma ou mais classes em uma classe mais genérica ou separação de uma classe em uma ou mais classes específicas

68 9) O Modelo de Objetos – Principais Conceitos
Pode-se ter uma hierarquia ou um entrelaçamento Pode-se herança múltipla Atributos e serviços comuns devem ser colocados no nível superior Deve satisfazer 100% a regra is-a

69 9) O Modelo de Objetos – Principais Conceitos
_________

70 9) O Modelo de Objetos – Principais Conceitos

71 9) O Modelo de Objetos – Principais Conceitos

72 9) O Modelo de Objetos – Principais Conceitos

73 9) O Modelo de Objetos – Principais Conceitos
Agregação/Decomposição representa um composto e suas partes um inteiro pode ser decomposto em diferente partes, ou várias partes podem ser agregadas em um composto

74 9) O Modelo de Objetos – Principais Conceitos

75 9) O Modelo de Objetos – Principais Conceitos
Agregação pode ser: Composição: a parte pertence apenas a um único composto Compartilhamento: a parte pode pertencer a mais de um composto

76 9) O Modelo de Objetos – Principais Conceitos

77 9) O Modelo de Objetos – Principais Conceitos
Métodos ou Serviços Processamento realizado por um objeto que indica o seu comportamento, em função do recebimento de uma mensagem Mensagens Ativação de um método. Um objeto se utiliza de um serviço ou se comunica com outro objeto enviando uma mensagem

78 9) O Modelo de Objetos – Principais Conceitos
Ligação Dinâmica (late binding) Mecanismo pelo qual se decide o destino de uma mensagem em tempo de execução Ex: int (*f)(); a função só definida i =f();  durante a execução

79 9) O Modelo de Objetos – Principais Conceitos
Sobrecarga de operadores (Overloading) Operações de mesmo nome, mas implementadas de maneira diferente Ex: operações de adição, subtração implementadas diferentemente para real e inteiro

80 9) O Modelo de Objetos – Principais Conceitos
Polimorfismo Possibilidade de uma função poder manipular valores com tipos (formas) diversas Ex: function comp(L:lista):integer  qualquer tipo de lista (genérico) mesma implementação

81 9) O Modelo de Objetos – Principais Conceitos

82 9) O Modelo de Objetos – Principais Conceitos
Construtor/Destrutor Função para criação/remoção de instâncias de objetos/classes Overriding (ou Sobreposição) Mecanismo para redefinir ou tornar um atributo não aplicável

83 9) O Modelo de Objetos – Principais Conceitos
classe abstrata – classe virtual

84 9) O Modelo de Objetos – Principais Conceitos
classe abstrata – classe virtual

85 9) O Modelo de Objetos – Diagrama de Classes
Composto pelas classes de objetos, atributos, associações entre classes e métodos

86 9) O Modelo de Objetos – Diagrama de Classes Como Construir
Na fase de análise constrói-se primeiramente um diagrama de classes sem se preocupar em definir os métodos, ao qual chamaremos de Modelo Conceitual Na fase de projeto os métodos são adicionados e o Modelo Conceitual refinado gerando o Diagrama de Classes

87 10) O Modelo Formal Utilizam notações matemáticas e podem ser empregados em qualquer estágio da especificação de um sistema Utilizam operadores relacionais: >, <,= ... operadores lógicos: ^, ~ ... quantificadores: ,  (para todo, existe) teoria dos conjuntos: ,,,, ...

88 10) O Modelo Formal Especifica-se uma função em termos de:
Pré-condições: para a função ser executada Pós-condições: para a função terminar Predicados sobre entradas e saídas das funções, geralmente parâmetros, dados

89 10) O Modelo Formal Passos
Estabelecer restrições para os valores de entrada Estabelecer restrições para os valores de saída Combinar esses predicados em pré e pós-condições

90 10) O Modelo Formal Ex1) especificar que o código digitado é um código cadastrado na base da biblioteca  b  biblioteca/ (b.código=código_biblioteca) Ex2) especificar que todo exemplar identificado por n_item (número do item) pertence a alguma biblioteca  e  exemplar/ pertence(b.código, e.n_item)

91 10) O Modelo Formal Ex3) especificar função Pré-condição Pós-condição
localiza_exemplar(exemplar_disponível:string):string Pré-condição  b  biblioteca/ pertence(b.código, exemplar_disponível) Pós-condição  b  biblioteca/ (b.nome=localiza_exemplar(exemplar_diponível) ^ pertence(b.código, exemplar_disponível)

92 10) O Modelo Formal Ex4) especificar que um exemplar está disponível em apenas uma biblioteca e reservado apenas para disciplinas de sua área  e  exemplar ( b1,b2  biblioteca (disponível (b1,e) ^ disponível (b2,e)) b1=b2)) ^ ( d  disciplina (reservado(d,e))  area (d,e))

93 10) O Modelo Formal – Linguagem Z
Baseada em teoria dos conjuntos e lógica de primeira ordem Constrói-se um esquema que agrupa declarações de variáveis e predicados que restrigem os valores dessas variáveis. Ex: ______ x ________ Inível: F N decl. var. declarações ______________ ________________ Inível predicado predicados outras linguagens, VDN, existem especificações matemáticas, lógicas e e algébricas.