1

Engenharia de Requisitos

2

Objetivos Descrever as principais atividades

da engenharia de requisitos Introduzir técnicas para a

elicitação e análise de requisitos Descrever validação de requisitos Discutir o gerenciamento de

requisitos

3

O Processo da Engenharia de Requisitos

Estudo deviabilidade

Relatório deviabilidade

Elicitação derequisitos e

análise

Modelos dosistema

Especificaçãode requisitos

Validaçãode requisitos

Requisitos dousuário e do

sistema

Documento derequisitos

4

Estudo de Viabilidade O que é um estudo de viabilidade? O que estudar e concluir? Benefícios e custos Análise de custo/benefício Alternativas de comparação

5

Estudo de Viabilidade Estudo que indica se o esforço em

desenvolver a idéia vale a pena Visa tanto a tomada de decisão Como a sugestão de possíveis

alternativas de solução

6

Estudo de Viabilidade Deve oferecer informações para

ajudar na decisão Se o projeto pode ou não ser feito Se o produto final irá ou não

beneficiar os usuários interessados Escolha das alternativas entre as

possíveis soluções Há uma melhor alternativa?

7

O Que Estudar? Sistema organizacional apresentado

Usuários, políticas, funções, objetivos, etc. Problemas com o sistema apresentado

Inconsistências, funcionalidades inadequadas, performance, etc.

Objetivos e outros requisitos para o novo sistema O que precisa mudar?

8

O Que Estudar? Restrições

Incluindo requisitos não-funcionais do sistema (superficialmente)

Alternativas possíveis Sistema atual é geralmente uma das

alternativas Vantagens e desvantagens das

alternativas

9

Testes de Viabilidade Operacional

Medida do grau de adequação da solução para a organização

Avaliação de como as pessoas se sentem sobre o sistema/projeto

Técnica Avaliação da praticidade de uma

solução técnica específica e a disponibilidade dos recursos técnicos e dos especialistas

10

Testes de Viabilidade Cronograma

Avaliação de quão razoável está o cronograma do projeto

Econômica Avaliação de custo-eficiência de um

projeto ou solução Conhecida como análise de

custo/benefício

11

Viabilidade Operacional Avalia a urgência do problema (visão e

fases de estudo) ou a aceitação da solução (definição, seleção, aquisição, e fases do projeto)

Há dois aspectos da viabilidade operacional a serem considerados O problema vale a pena ser resolvido ou a

solução proposta para o problema funcionará? Como o usuário final e a gerência sentem-se

sobre o problema (solução)?

12

Viabilidade Técnica A solução ou a tecnologia proposta

é prática? Já possuímos a tecnologia

necessária? Já possuímos o conhecimento

técnico necessário?

13

Viabilidade de Cronograma Dado nosso conhecimento técnico,

os prazos dos projetos são razoáveis? Alguns projetos são iniciados com

prazos específicos Você precisa determinar se os prazos são

obrigatórios ou desejáveis Se são mais desejáveis que obrigatórios, o

analista pode propor outros cronogramas

14

Viabilidade Econômica Talvez a mais crítica

Durante as fases iniciais do projeto, a análise da viabilidade econômica consiste em julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos

Tão logo os requisitos específicos e soluções sejam identificados, o analista pode levar em consideração os custos e benefícios de cada alternativa

Isso é chamado de análise de custo-benefício

15

Tipos de Custos Custos de desenvolvimento de

sistemas Desenvolvimento e aquisição Custos de instalação e de

conversão Custos operacionais (contínuo)

Manutenção Pessoal

16

Análise Custo-Benefício Há três técnicas principais

Análise do retorno financeiro (payback analysis)

Retorno do investimento (return on investments)

Valor atual líquido (Net present value)

17

Análise de Retorno do Investimento A técnica de análise de retorno do

investimento (ROI) compara os benefícios das diferentes soluções ou projetos

O ROI para uma solução ou projeto é a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida

18

Análise de Retorno do Investimento O ROI para uma solução ou projeto

potencial é calculado como a seguir: ROI = (Benefícios totais - Custos totais) /

Custos totais ROI = valor atual líquido / Custos totais

Ex: ROI = (22508,64-17321,20)/ 17321,20= 29,95%

EX: ROI = 5187,44/ 17321,20 = 29,95% A solução que oferecer o ROI mais alto é

a melhor alternativa

19

Matriz de Viabilidade Como nós comparamos

alternativas quando existem vários critérios de seleção e nenhuma das alternativas é superior em todos os aspectos?

Use uma Matriz de Análise de Viabilidade!

20

Relatório de Viabilidade Após o esforço inicial, discutido

anteriormente, deve-se elaborar um relatório de viabilidade Para cada aspecto apresentado, deve

haver seção de avaliação Deve haver uma seção conclusiva

sobre a melhor alternativa ou que o sistema não é viável

21

Exercício Determine a viabilidade de (+ROI):

1. Sistema para uma padaria de pequeno porte (Só caixa, no balcão também, etc.);

2. Sistema inteligente de preenchimento do IRPF pela própria pessoa física;

3. Sistema para gerar alocação de docentes, salas, horários, local de forma otimizada.

22

Elicitação de requisitos e análise Esta atividade divide-se em dois

esforços maiores: Elicitação dos requisitos em si

Técnicas de elicitação Análise do que foi elicitado

Processo de análise

23

Que é um requisito? Tanto pode ser

Uma declaração abstrata de alto nível de um serviço

Como uma restrição do sistema Quanto uma especificação

funcional matemática detalhada

24

Elicitação de Requisitos Também denominada de descoberta de

requisitos Envolve pessoal objetivando descobrir o

domínio de aplicação, serviços que devem ser fornecidos bem como restrições

Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (Stakeholders).

25

Visão dos Requisitos Requisitos do Usuário

Declarações em linguagem natural com diagramas de serviços que o sistema deve oferecer e suas restrições operacionais. Escrito para os clientes

Requisitos do Sistema Documento estruturado com descrições

detalhadas sobre os serviços do sistema. Contrato entre cliente e fornecedor

26

Tipos de Requisitos Requisitos Funcionais

Requisitos Não-Funcionais

Requisitos de Domínio

27

Requisitos Funcionais Descreve funcionalidade e serviços

do sistema Depende do

Tipo do software Usuários esperados Tipo do sistema onde o software é

usado

28

Exemplos de R.F. [RF001] Usuário pode pesquisar todo ou

um sub-conjunto do banco de dados [RF002] Sistema deve oferecer

visualizadores apropriados para o usuário ler documentos armazenados

[RF003] A todo pedido deve ser associado um identificador único (PID), o qual o usuário pode copiar para a área de armazenamento permanente da conta

29

Exercício Dê alguns exemplos de R.F.s para:

1. Sistema da padaria de pequeno porte;

2. Sistema inteligente de preenchimento do IRPF;

3. Sistema de alocação docente.

30

Requisitos Não-Funcionais Definem propriedades e restrições do

sistema (tempo, espaço, etc) Requisitos de processo também podem

especificar o uso de determinadas linguagens de programação, método de desenvolvimento

Requisitos não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, sistema inútil.

31

Requisitos Não-Funcionais Devido à sua própria definição,

requisitos não-funcionais são esperados mensuráveis

Assim, deve-se associar forma de medida/referência a cada requisito não-funcional elicitado

32

Medidas de Requisitos(Não-Funcionais)

Propriedade MedidaVelocidade Transações processadas/seg

Tempo de resposta do usuário/eventoTamanho K bytes

No de chips de RAMFacilidade de uso Tempo de treinamento

No de quadros de ajudaConfiabilidade Tempo médio de falhas

Probabilidade de indisponibilidadeTaxa de ocorrência de falhas

Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após falha

Portabilidade Percentual de declarações dependentes do destinoNo de sistemas destino

33

Classificação de R. N. F. Requisitos do Produto

Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.)

Requisitos Organizacionais Conseqüência de políticas e procedimentos

organizacionais (padrões de processo usados, requisitos de implementação, etc.)

Requisitos Externos Conseqüência de fatores externos ao

sistema e ao processo de desenvolvimento (legislação, etc.)

34

Exemplos de R. N. F. Requisitos do Produto

[RNF001] Toda consulta ao B.D., baseada em código de barras, deve resultar em até 5 s

Requisitos Organizacionais [RNF002] Todos os documentos entregues

devem seguir o padrão de relatórios XYZ-00 Requisitos Externos

[RNF003] Informações pessoais do usuário não devem ser vistas pelos operadores do sistema

35

Exercício Dê alguns exemplos de R.N.F.s

para: 1. Sistema da padaria de pequeno

porte; 2. Sistema inteligente de

preenchimento do IRPF; 3. Sistema de alocação docente.

36

Requisitos de Domínio Derivados do domínio da aplicação e

descrevem características do sistema e qualidades que refletem o domínio

Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas

Se requisitos de domínio não forem satisfeitos, o sistema pode tornar-se impraticável

37

Requisitos de Domínio (Problemas) Entendimento

Requisitos são descritos na linguagem do domínio da aplicação

Não é entendido pelos engenheiros de software que vão desenvolver a aplicação

Implicitude Especialistas no domínio entendem a

área tão bem que não tornam todos os requisitos de domínio explícitos

38

Requisitos de Domínio (Exemplo 1) A desaceleração do trem deve ser

computada através da fórmulaDtrem=Dcontrole+Dgradiente onde ...

39

Exercício Dê alguns exemplos de domínio

para: 1. Sistema da padaria de pequeno

porte; 2. Sistema inteligente de

preenchimento do IRPF; 3. Sistema de alocação docente.

40

RequisitosRequisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário

41

Técnicas de Elicitação Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos

42

Entrevistas Técnica direta

Pode ser usada na análise do problema e na elicitação de requisitos

Objetivo Entender os problemas reais e soluções

potenciais das perspectivas dos usuários, clientes, e outros stakeholders

43

Entrevistas Quem são o cliente e o usuário? Possuem necessidades diferentes? Quais são suas

Capacidades Backgrounds Ambientes, etc.

Qual é o problema? Como é resolvido atualmente?

44

Entrevistas Qual a razão para resolvê-lo? Qual o valor de uma solução bem-

sucedida? Onde mais uma solução pode ser

encontrada?

Note que algumas dessas perguntas jáforam feitas no estudo de viabilidade.

45

Questionários Aplicabilidade a mercados específicos

Onde perguntas são bem definidas Hipóteses

Perguntas relevantes podem ser decididas antecipadamente

Leitor ouve da maneira desejada Suprime o que é bom sobre análise

Úteis após uma entrevista inicial

46

Casos de Uso Discuta com o cliente o que o

sistema fará Identique quem interage com o

sistema Identique que interfaces o sistema

terá

47

Casos de Uso Verifique se não há requisitos

faltando Verifique que os desenvolvedores

entendem os requisitos Vantagem é ter apelo visual dos

requisitos mais relevantes do cliente

48

Engenheiro de requisitos Assume a função do usuário ou cliente

Entender o domínio do problema Cliente

Assume a função do usuário Entender os problemas que podem passar

Jogo de Funções

49

Brainstorming Regras para Brainstorming

Estabeleça o objetivo da sessão Gere quantas idéias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as idéias

50

Workshop de Requisitos Põe todos os stakeholders

juntos por um período intensivo (focado)

Facilitador conduz a reunião Todos têm sua vez de falar Resultados são disponíveis

imediatamente Provê um ambiente para

aplicar outras técnicas de elicitação

51

Exercício Quais técnicas poderiam ser

usadas em: 1. Sistema da padaria de pequeno

porte; 2. Sistema inteligente de

preenchimento do IRPF; 3. Sistema de alocação docente.

52

Análise de Requisitos

Entendimentodo domínio

Coleta derequisitos

Classificação

Definição eespecificaçãode requisitos

Resoluçãode conflito

Atrib. Prioridade

Validaçãodos requisitos

Entrada doprocesso

Documentode requisitos

1

2

3

4

5

6

7 8

53

Entendimento do Domínio Desenvolver sistemas envolve

domínios além de software e hardware

Podemos ter que entender sobre Contabilidade Saúde Supermercados Etc.

54

Coleta de Requisitos Como vimos anteriormente, a

coleta de requisitos é feita através de técnicas

Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados

Resulta em documento preliminar (draft)

55

Classificação dos Requisitos Esta etapa consiste basicamente em

agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos

Por exemplo Deve ser possível consultar o preço de

uma mercadoria A consulta deve retornar uma resposta em

no máximo 5s

56

Problema da Análise de Requisitos Stakeholders em geral não sabem

o que querem Stakeholders expressam requisitos

em sua terminologia Stakeholders diferentes podem

gerar requisitos conflitantes

57

Problema da Análise de Requisitos Fatores políticos e organizacionais

podem influenciar os requisitos do sistema

Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho mudar

58

Resolução de Conflitos É normal que ocorram requisitos

conflitantes Por exemplo

R-23: O sistema deve ... R-45: O sistema não deve ...

Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)

59

Atribuição de Prioridade Alguns requisitos são mais

urgentes que outros É essencial determinar a

prioridade dos requisitos junto ao cliente

Requisitos de maior prioridade são considerados em primeiro lugar

60

Prioridade Requisitos podem ser vistos em

três classes distintas Essenciais Importantes Desejáveis

Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

61

Exemplo de Prioridade [RF001] Consulta X ao B.D. deve

retornar dados A, B, C Prioridade: Essencial

[RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y Prioridade: Importante

[RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados Prioridade: Desejável

62

Validação dos Requisitos Será que realmente entendi o que

o cliente deseja? Devo me certificar de que não

houve falha em nossa interação (comunicação)

Há diversas técnicas de validação

63

Validação de Requisitos Demonstrar que os requisitos definem

o sistema que o cliente realmente deseja

Custos com erros de requisitos são altos Consertar um erro de requisitos após

entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

64

Técnicas de Validação de Requisitos Revisões de Requisitos

Análise manual sistemática dos requisitos Prototipação

Uso de modelo executável do sistema para avaliar requisitos

Geração de Casos de Teste Desenvolver testes específicos para os

requisitos para avaliá-los Análise de Consistência Automática

Avaliar uma especificação dos requisitos

65

Gerenciamento de Requisitos Gerenciamento de requisitos é o

processo de controlar as mudanças dos requisitos durante O processo da engenharia de

requisitos E desenvolvimento do sistema

66

Gerenciamento de Requisitos Requisitos são inevitavelmente

incompletos e inconsistentes Requisitos novos surgem durante o

processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido

Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

67

Rastreamento Responsável por dependências

entre requisitos, suas origens e projeto do sistema

Rastreamento de Origem Associação entre requisitos e

stakeholders que propuseram tais requisitos

68

Rastreamento Rastreamento de Requisitos

Associação entre requisitos dependentes Rastreamento de Projeto

Associação dos requisitos com o projeto Usar hipertexto ou referência

cruzada Ou matriz de rastreamento

69

1.Rastrear requisitos do usuário nos do sistema

2.Rastrear requisitos no projeto

3.Rastrear requisitos nos procedimentos de teste

4.Rastrear requisitos do usuário no plano

Projeto

Modelos Suítes Teste

Teste

2 3

Req A

1

RequisitosProduto

(Características)

RequisitosDetalhados

(Casos de Uso) Req B

Plano

Doc. Usuário

4

Rastreamento

70

Links dos requisitos devem ser marcados como “revisar”

Links “revisar” devem ser analisados

Req A antes

“if return value > $5”

Req B

Req C

“if return value > $2”

Req A depois

Req C

Req B

Rastreamento: Análise de Impacto

71

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 1. Introdução

1.1 Propósito do documento 1.2 Escopo do sistema 1.3 Definições, acrônimos e

abreviaturas 1.4 Referências 1.5 Descrição do resto do documento

72

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 2. Descrição geral

2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 Assertivas e dependências

73

Documento de Requisitos Fonte: IEEE/ANSI (830-1998) 3. Requisitos específicos

requisitos funcionais, não-funcionais, GUI com o usuário:

funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...

Apêndices Índice