ENGENHARIA DE REQUISITOSMARCELA SANTOSApresentação baseada no material do professor Alexandre Vasconcelos

(amlv@cin.ufpe.br)

1

“Todos os projetos são viáveis,

desde que tenhamilimitados recursos e

tempo infinito!”

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

4

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

O PROCESSO DA ENGENHARIA DE REQUISITOS

23

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

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

24

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

25

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

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

27

TIPOS DE REQUISITOS

Requisitos Funcionais

Requisitos Não-Funcionais

Requisitos de Domínio

28

REQUISITOS FUNCIONAIS

Descreve funcionalidade e serviços do sistema

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

29

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

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

33

MEDIDAS DE REQUISITOS(NÃO-FUNCIONAIS)

34

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

CLASSIFICAÇÃO DE R. N. F. Requisitos do Produto

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

Requisitos OrganizacionaisConseqüência de políticas e

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

Requisitos ExternosConseqüência de fatores externos ao

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

35

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 impraticável

38

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

39

REQUISITOS

42

Requisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário

TÉCNICAS DE ELICITAÇÃO

Entrevistas Questionários Casos de Uso Jogo de Funções Brainstorming Workshop de Requisitos

43

ANÁLISE DE REQUISITOS

54

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

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.

55

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)

56

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

57

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

58

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

59

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)

60

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

61

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

62

EXEMPLO DE PRIORIDADE

[RF001] Consulta X ao B.D. deve retornar dados A, B, CPrioridade: Essencial

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

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

63

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

64

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

65

TÉCNICAS DE VALIDAÇÃO DE REQUISITOS

Revisões de RequisitosAnálise manual sistemática dos requisitos

PrototipaçãoUso 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áticaAvaliar uma especificação dos requisitos

66

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

67

GERENCIAMENTO DE REQUISITOS

Requisitos são inevitavelmente incompletos e inconsistentesRequisitos 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

68

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

69

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

70

RASTREAMENTO

71

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: ANÁLISE DE IMPACTO

72

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

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

73

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

74

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

75

DIAGRAMAS DE CASOS DE USO

76

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

77

USE CASE

Seqüência de ações, executada pelo sistema, que gera um resultadoDe valor

observávelE para ator

particular

78

Função

Procedimento computacional/algorítmico atômico

USE CASE E ATOR

Alguém ou alguma coisa (fora do sistema) que interage com o sistema

79

Emissor/Receptor

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

81

USE CASE E ATOR

82Função

Emissor

Passo 1Passo 2…Passo N

Descrição

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

83

EXEMPLO DE USE CASE E ATOR

84

Cliente

Transferirdinheiro

Sacardinheiro

Consultarsaldo

Valor deresultado

observável

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?

85

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

86

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

93

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

94

INCLUSÃO

Como exemplo, tanto “Sacar dinheiro” quanto “Consultar saldo” necessitam da senhaPode-se criar novo use case “Autenticar

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

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

95

INCLUSÃO

96

Sacardinheiro

Consultarsaldo

Autenticarusuário

<< include >> << include >>

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

97

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

98

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

99

EXTENSÃO

100

Atendimento

Pontos de extensãourgente

Atendimentode urgência

<< extend >>(urgente)

EXTENSÃO

Descrição de Atendimento Fluxo de Eventos Principal:

Colete os itens do pedido. (urgente). Submeta pedido para processamento.

101

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

102

ESPECIALIZAÇÃO

103

AtendimentoAtendimentode urgência

ClienteClientecomercial

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

104

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)

105

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”

106

EXEMPLO DE FLUXO DE EVENTOS

Um esboço inicial sobre Sacar dinheiro seria

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

107

EXEMPLO DE FLUXO DE EVENTOS

Um esboço inicial sobre Sacar dinheiro seria

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

110

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)

111

EXEMPLO DE SUB-FLUXOS

Seja o use case Validar usuárioFluxo 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. 112

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

113

DIAGRAMA DE ATIVIDADES: EXEMPLO

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

116

EXEMPLO DE DIAGRAMA

117

Transação decartão

Clientecorporativo

Clienteindividual

Cliente Instituiçãovendedora

Financeira

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

Processafatura

Reconciliatransações

Gerenciaconta

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.

118