1

Engenharia de Requisitos

Alexandre Monteiro

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

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

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

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 não prático

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 ...

40

RequisitosRequisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário =df

41

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

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 muda

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.)

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

74

Diagramas de Casos de Uso

Alexandre Vasconcelos(amlv@cin.ufpe.br)

75

Objetivos Introduzir conceitos de use case, ator

e fluxo de eventos Apresentar sub-fluxos de eventos Discutir sobre identificação, evolução

e organização de use cases Apresentar notação UML para reusar

atores e use cases

76

Use Case Seqüência de

ações, executada pelo sistema, que gera um resultado De valor

observável E para ator

particular

Função

Procedimento computacional/algorítmico atômico

77

Use Case e Ator Alguém ou

alguma coisa (fora do sistema) que interage com o sistema

Emissor/Receptor

79

Use Case e Ator A descrição de um use case define

o que o sistema faz quando o use case é realizado

A funcionalidade do sistema é definida por um conjunto de use cases, cada um representando um fluxo de eventos específico

80

Use Case e Ator

FunçãoEmissor

Passo 1Passo 2…Passo N

Descrição

81

Exemplo de Use Case e Ator Cliente de banco pode usar um

caixa automático para sacar dinheiro, transferir dinheiro ou

consultar o saldo da conta Ator: Cliente Use cases: Sacar dinheiro,

transferir dinheiro e consultar saldo

82

Exemplo de Use Case e Ator

Cliente

Transferirdinheiro

Sacardinheiro

Consultarsaldo

Valor deresultado

observável

83

Identificando Use Cases Em geral, difícil decidir entre um

ou vários use cases Por exemplo, seriam use cases

Inserir cartão em um Caixa Automático?

Entrar com a senha? Receber o cartão de volta?

84

Identificando Use Cases Representar valor observável para

ator Pode-se determinar

De interações (seqüência de ações) com o sistema que resultam valores para atores

Satisfaz um objetivo particular de um ator que o sistema deve prover

91

Reuso em Use Cases Comportamento comum a mais de

dois use cases (ou forma parte independente) Pode-se modelar como use case para

ser reusado Há três possibilidades

Inclusão Extensão Generalização/Especialização

92

Inclusão Vários use cases possuem texto de

fluxo de eventos Comum/idêntico Sempre usado

Equivalente a fatoração feita em programação através de sub-programas #include da linguagem C

93

Inclusão Como exemplo, tanto “Sacar dinheiro”

quanto “Consultar saldo” necessitam da senha Pode-se criar novo use case “Autenticar

usuário” e incluí-lo Mas atenção

NÃO SE DEVE CRIAR USE CASES MÍNIMOS Deve haver ganho no reuso

94

Inclusão

Sacardinheiro

Consultarsaldo

Autenticarusuário<< include >> << include >>

95

Inclusão Descrição de Consultar saldo

Fluxo de Eventos Principal: include (Autenticar usuário). Sistema

pede a Cliente que selecione tipo de conta (corrente, etc). ...

96

Extensão Use case pode ser estendido por

outro Extensão de funcionalidade/Caso

excepcional Extensão ocorre em pontos

específicos Pontos de extensão

97

Extensão Há também inclusão de texto (fluxo

de eventos) Porém sob condições particulares

Pode ser usada para Simplificar fluxos de eventos complexos Representar comportamentos opcionais Lidar com exceções

98

Extensão

Atendimento

Pontos de extensãourgente

Atendimentode urgência

<< extend >>(urgente)

99

Extensão Descrição de Atendimento

Fluxo de Eventos Principal: Colete os itens do pedido. (urgente).

Submeta pedido para processamento.

100

Especialização Use case pode especializar outro

Adição/refinamento do fluxo de eventos original

Especialização permite modelar comportamento de estruturas de aplicação em comum

101

Especialização

AtendimentoAtendimentode urgência

ClienteClientecomercial

102

Fluxo de Eventos Parte mais importante de um use

case Atividade de requisitos

Define a seqüência de ações entre o ator e o sistema

103

Fluxo de Eventos Geralmente em linguagem natural

Uso preciso de termos definidos no glossário de acordo com o domínio do problema

Também expresso formalmente Pré e pós-condições (ou pseudo-

código)

104

Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar

dinheiro seria1. O use case inicia quando o Cliente

insere um cartão no CA. Sistema lê e valida informação do cartão

2. Sistema pede a senha. Cliente entra com a senha. Sistema valida a senha.

3. Sistema pede seleção do serviço. Cliente escolhe “Sacar dinheiro”

105

Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar

dinheiro seria4. Sistema pede a quantia a sacar. Cliente

informa.5. Sistema pede seleção da conta

(corrente, etc). Cliente informa.6. Sistema comunica com a rede para

validar a conta, senha e o valor a sacar.

106

Exemplo de Fluxo de Eventos Um esboço inicial sobre Sacar

dinheiro seria7. Sistema pede remoção do cartão.

Cliente remove.8. Sistema entrega quantia solicitada.

108

Fluxo de Eventos Na descrição do que o sistema faz

através de fluxos de eventos completos Surgem caminhos alternativos Casos diferentes a considerar Efeitos/valores diferentes a produzir

Eventualmente descreve todos esses caminhos possíveis

109

Sub-fluxos de Eventos Fluxo de eventos visto como

Vários sub-fluxos de eventos Sub-fluxos são descritos como

Principal Alternativos/excepcionais

Abordagem visa reuso de fluxos de eventos (sub-fluxos)

110

Exemplo de Sub-fluxos Seja o use case Validar usuário

Fluxo principal: O use case inicia quando o sistema pede ao Cliente a

senha. Cliente entra com senha. Sistema verifica se a senha é válida. Se a senha é válida, sistema confirma e termina o use case.

Fluxo excepcional: Cliente pode cancelar a transação a qualquer momento

pressionando a tecla ESC, reiniciando o use case. Nenhuma modificação é feita na conta do Cliente.

Fluxo excepcional: Se Cliente entra com senha inválida, o use case

reinicia.

111

Diagrama de Atividades Descreve fluxo de tarefas

Aspectos dinâmicos de um sistema Podem também ser usados para criar

sistemas executáveis Depende do nível de detalhamento e

grau de execução dos elementos usados Alternativa para modelar fluxos de

eventos de casos de uso

112

Elementos de um Diag. Ativ.

114

Diagramas de Use Cases Caracterizar limites da

funcionalidade do sistema Use cases são organizados dentro de

um diagrama Em diagramas de use cases

Atores são relacionados por generalização/especialização

115

Exemplo de Diagrama

Transação decartão

Clientecorporativo

Clienteindividual

Cliente Instituiçãovendedora

Financeira

Sistema de validaçãode cartão de crédito

Processafatura

Reconciliatransações

Gerenciaconta

116

Bibliografia Sommerville, I. Software

Engineering Kruchten, P. The Rational Unified

Process: An Introduction. 2nd Ed Booch, G. et al. The Unified

Modeling Language User Guide.