Engenharia de Software Processos de Engenharia de Requisitos Abr/2010.
Engenharia de Requisitos
description
Transcript of Engenharia de Requisitos
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