Trabalho de Engenharia de Software

Faculdade dos GuararapesTurma: 5NA

Tema: Engenharia de RequisitosAlunos: Walter Fonseca Junior

Paula Michelly v. Silva Raugil da Costa Junior

Evangelisto Nascimento Filho

2

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

19

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

20

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

21

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

22

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

23

Tipos de Requisitos

• Requisitos Funcionais

• Requisitos Não-Funcionais

• Requisitos de Domínio

24

Requisitos Funcionais

• Descreve funcionalidade e serviços do sistema• Depende do

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

25

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

26

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.

27

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

28

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

29

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

30

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

31

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

32

Requisitos

Requisitos

Não-funcionais

Organização

Funcionais Domínio

Produto Externo

SistemaUsuário

33

Técnicas de Elicitação

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

43

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

44

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.

45

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)

46

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

47

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

48

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

49

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)

50

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

51

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

52

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

53

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

54

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

55

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

56

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

57

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

58

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

59

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

60

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

61

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

62

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

63

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

64

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

65

Diagramas de Casos de Uso

66

Use Case

• Seqüência de ações, executada pelo sistema, que gera um resultado– De valor observável– E para ator particularFunção

Procedimento computacional/algorítmico atômico

67

Use Case e Ator

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

Emissor/Receptor

69

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

70

Use Case e Ator

FunçãoEmissor

Passo 1Passo 2…Passo N

Descrição

71

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

72

Exemplo de Use Case e Ator

Cliente

Transferirdinheiro

Sacardinheiro

Consultarsaldo

Valor deresultado

observável

73

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?

74

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

80

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

81

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

82

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

83

Inclusão

Sacardinheiro

Consultarsaldo

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

84

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

85

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

86

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

87

Extensão

Atendimento

Pontos de extensãourgente

Atendimentode urgência

<< extend >>(urgente)

88

Extensão

• Descrição de Atendimento– Fluxo de Eventos Principal:

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

89

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

90

Especialização

AtendimentoAtendimentode urgência

ClienteClientecomercial

91

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

92

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)

93

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”

94

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.

95

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.

96

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

97

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)

98

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.

99

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

Diagrama de atividades: exemplo

100

101

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

102

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

103

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.• Alexandre Vasconcelos,(amlv@cin.ufpe.br)