Engenharia de software

MODELOS DE PROCESSO DE SOFTWARE

1
 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

2
O Processo da Engenharia de Requisitos
Estudo de Elicitação de
viabilidade requisitos e
análise
Especificação
de requisitos
Validação
de requisitos
Relatório de
viabilidade

Requisitos do
usuário e do
sistema

Modelos do Documento de
sistema requisitos
3
 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

4
 Estudo de Viabilidade

Estudo que indica se o esforço em desenvolver a ideia vale a pena

Visa tanto a tomada de decisão

Como a sugestão de possíveis alternativas de solução

5
 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 ?

6
 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?

7
 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

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

9
 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

10
 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)?

11
 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?

12
 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

13
 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
14
 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
 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)

16
 Análise de Retorno do Investimento

A técnica de análise de retorno do investimento (ROI - Return On

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

17
 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

18
 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!

19
 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

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

21
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

22
 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

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

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

Propriedade Medida
Velocidade Transações processadas/seg
Tempo de resposta do usuário/evento
Tamanho K bytes
No de chips de RAM
Facilidade de uso Tempo de treinamento
No de quadros de ajuda
Confiabilidade Tempo médio de falhas
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Robustez Tempo de reinício após falha
Percentual de eventos causando falhas
Probabilidade de corrupção de dados após falha
Portabilidade Percentual de declarações dependentes do destino
No de sistemas destino
34
 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
• Consequê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
 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.

37
 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
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 de Domínio (Exemplo 1)

• A desaceleração do trem deve ser computada através

da fórmula
• Dtrem=Dcontrole+Dgradiente
onde ...

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

41
 Requisitos

Requisitos

Usuário =df Sistema

Funcionais Não-funcionais Domínio

Produto Organização Externo

42
 Técnicas de Elicitação

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

43
 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

44
 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?

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

47
 Casos de Uso

• Discuta com o cliente o que o sistema fará

• Identique quem interage com o sistema
• Identique que interfaces o sistema terá

48
 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

49
 Jogo de Funções

• 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

50
 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

51
 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

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

53
 Análise de Requisitos

Definição e
Documento
especificação
de requisitos
de requisitos
7 8

Validação
dos requisitos
Entendimento 6
Atrib. Prioridade
do domínio
Entrada do 1
processo 5

2 4
Coleta de Resolução
requisitos de conflito
3

Classificação 54
 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 muda.

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 consulta 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, 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

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

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

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

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

1. Rastrear requisitos do
Requisitos
usuário nos do sistema
Produto Req A 2. Rastrear requisitos no
(Caracter.) projeto
1 3. Rastrear requisitos nos
procedimentos de teste
Requisitos 4.Rastrear requisitos do
Detalhados Req B
(Casos de Uso)
usuário no plano
2 3 4

Projeto Teste Doc. Usuário

Modelos Suítes Teste Plano 71

 Rastreamento: Análise de Impacto

Req A antes Req A depois

“if return value > $5” “if return value > $2”

Req B Req B

Req C Req C

 Links dos requisitos devem ser marcados como

“revisar”
 Links “revisar” devem ser analisados
72
 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