Upload
duongque
View
217
Download
0
Embed Size (px)
Citation preview
1Engenharia de Requisitos - Universidade da Madeira
Engenharia de Requisitos3 - Iniciando um processo de ER
Pedro CamposProfessor Auxiliar, Universidade da Madeira
http://dme.uma.pt/pcampos - [email protected]
2Engenharia de Requisitos - Universidade da Madeira
Agenda
• Stakeholders e fronteiras
• Objectivos e cenários
• Viabilidade e risco
3Engenharia de Requisitos - Universidade da Madeira
Ponto de partida
• Stakeholders– Importância da ligação ao cliente– Quem são os stakeholders?
• Fronteiras– Como definir o âmbito do problema?
• Objectivos e cenários– Forma útil de organizar uma colecção inicial de informação
• Viabilidade– Como conduzir um estudo de viabilidade– Como escolher que projecto concretizar
• Risco– Gestão contínua do risco– Identificar o risco através da análise de faltas
4Engenharia de Requisitos - Universidade da Madeira
Os “quatro mundos”
• Mundo do Sujeito– O sujeito do sistema de informação:
• Exº: clientes, contas e transacções para um sistema bancário
• Mundo da Utilização– O ambiente no qual o sistema será operado
• Exº: pessoas, como gestores, caixas, clientes; também se inclui processos de negócio como gerir umlevantamento, câmbio de uma moeda estrangeira
• Mundo do Sistema– O que o sistema faz no seu contexto operacional
– Que informação contém e que funções realiza• Exº: o sistema guarda todas as transacções numa base de dados, fornece saldos de conta, gera relatórios,
etc.
• Mundo do Desenvolvimento– Os processos de desenvolvimento, equipa, testes, escalonamentos, qualidades requeridas
• Exº: o sistema deve ser entregue em 12 meses, testado sob certificado ISO 9001, etc.
5Engenharia de Requisitos - Universidade da Madeira
Stakeholders
• Análise de stakeholders– Identificar todas as pessoas que têm de ser consultadas durante a aquisição de informação
• Exemplos:– Utilizadores
• Preocupados com as características e funcionalidades do novo sistema
– Designers• Querem construir um sistema perfeito ou reutilizar código existente
– Analistas de sistemas• Querem ter “os requisitos como deve ser”
– Pessoal de suporte ao utilizador e formação• Querem que o novo sistema seja fácil de usar e gerir
– Analista de negócio• Quer ter a certeza que “estamos melhores que a competição”
– Autores técnicos• Vão preparar os manuais e a documentação para o novo sistema
– O gestor de projecto• Quer completar o projecto a tempo, dentro do orçamento, alcançando todos os objectivos
– O Cliente• Paga!
6Engenharia de Requisitos - Universidade da Madeira
A ligação com os clientes
• Projectos bem sucedidos são os que apresentam maior ligação aos clientes... ?
Keil, M. and Carmel, E. 1995. Customer-developer links in software development. Commun. ACM 38, 5 (May. 1995), 33-44
7Engenharia de Requisitos - Universidade da Madeira
A ligação com os clientes
• Projectos bem sucedidos são os que apresentam maior ligação aos clientes... ?
Keil, M. and Carmel, E. 1995. Customer-developer links in software development. Commun. ACM 38, 5 (May. 1995), 33-44
8Engenharia de Requisitos - Universidade da Madeira
Dificuldades na Elicitação de Requisitos
• Conhecimento diluído sobre o domínio da aplicação– O conhecimento pode estar disperso sobre muitas fontes
– Haverá conflitos entre o conhecimento de diferentes fontes
• Conhecimento tácito– A malta acha difícil descrever conhecimento que emprega todos os dias
• Observação limitada– A malta pode estar muito ocupada a resolver os problemas usando o sistema actual
– A presença de um observador pode alterar o problema
• Enviesamento ( bias )– A malta pode não ser livre de exprimir o que nós precisamos de saber
– A malta pode não querer dizer o que nós precisamos de saber
9Engenharia de Requisitos - Universidade da Madeira
Exemplo* prático
• Área do problema:– Departamento de aprovação de empréstimos de um grande banco
– O analista de requisitos tenta elicitar as regras e procedimentos para aprovar umempréstimo
• Porque pode ser difícil:– Conhecimento implícito:
• Não há nenhum documento onde as regras de empréstimo estejam escritas
– Informação conflituosa:• Diferentes membros do departamento podem ter ideias diferentes sobre as regras
– Conhecimento tácito:• O processo de aprovação do empréstimo descrito pelos funcionários de aprovação de
empréstimos pode, de acordo com as nossas observações, ser muito diferente do que nos foidescrito
– Enviesamento:• Os funcionários podem recear que o sistema a desenvolver os irá substituir e deixá-los no
desemprego, portanto insistem na necessidade de conduzir uma análise “caso-a-caso” – paragarantir que só um humano pode realizar a tarefa!
*Exemplo por Steve Easterbrook.
10Engenharia de Requisitos - Universidade da Madeira
Considerações psicológicas
• Os peritos não estão habituados a descrever as coisas que fazem– Os mecanismos procedimentais são diferentes dos mecanismos declarativos
• O conhecimento declarativo torna-se procedimental com a aplicação repetitiva: os peritosperdem consciência daquilo que sabem e não realizam uma introspecção fiável!
• Problemas representacionais– Os peritos não possuem a linguagem para exprimir o conhecimento
• Linguagem natural não oferece a precisão necessária
• O analista de requisitos tem de criar, com o perito, uma linguagem adequada
• Fragilidade– O conhecimento é criado, não é extraído
• Os modelos do conhecimento são abstracções da realidade e portanto são inevitavelmenteselectivos
• A fragilidade é causada por simplificação de hipóteses: em vez de adicionar maisconhecimento, é necessário um modelo mais compreensível
11Engenharia de Requisitos - Universidade da Madeira
Enviesamento dos peritos
• O que é o enviesamento?– O enviesamento apenas existe em relação a um ponto de referência
– Nós não conseguimos perceber a realidade objectivamente• A realidade é interpretada através de filtros mentais ou modelos mentais
• É mediada pelos nossos sentidos e ligações neuronais
• Tipos de enviesamentos:– Enviesamento motivacional
• Os peritos fazem acomodações e ajustes a fim de agradar os entrevistadores e analistas derequisitos (ou qualquer outro tipo de público)
– Enviesamento cognitivo• Os peritos filtram a informação de modo que ela encaixe bem no seu modelo mental
12Engenharia de Requisitos - Universidade da Madeira
Fontes de enviesamento• Pressão social
– Respostas às pistas verbais e não-verbais do entrevistador
• Pensamento de grupo– Resposta às reacções dos outros peritos
• Impressão da gestão– Resposta a reacções imaginadas dos directores, gestores, clientes, etc.
• “Whishful thinking”– Resposta às esperanças ou possíveis ganhos
• Má interpretação– O analista interpreta selectivamente de forma a suportar as suas crenças correntes
• Má representação– O perito não consegue encaixar uma resposta no modo pretendido
• Ancoramento– Dados contraditórios são ignorados uma vez que a solução inicial esteja disponível
• Inconsistência– Tudo o que se assumiu previamente é esquecido
• Disponibilidade– Alguns dados são mais fáceis de recordar do que outros
• Subestimação da incerteza
13Engenharia de Requisitos - Universidade da Madeira
Decidindo o âmbito I
• Decidindo o âmbito do PROBLEMA:– Exemplo: problema da livraria
• “Os livros não estão ordenados a tempo do início das aulas.”
– Mas isso é apenas um sintoma. (Você pergunta ao gestor: “Porquê?”)• “Porque os professores não nos enviam as listas de livros com antecedência.”
– Isso é apenas um sintoma de outro problema? (pergunta aos professores: “Porquê?”)• “Porque não sabemos que aulas vamos dar com antecedência.”
– Isso é apenas um sintoma de outro problema? (pergunta aos directores: “Porquê?”)• “Porque nunca sabemos quem estará disponível para leccionar com antecedência”
– Isso é apenas um sintoma de outro problema? (pergunta ao presidente: “Porquê?”)• “Porque há incertezas em relação aos contratos, licenças sabáticas, etc.”
– Isso é apenas um sintoma de outro problema? (pergunta ao presidente: “Porquê?”)• “Porque os professores nunca aceitam as nossas ofertas de emprego a tempo”
– Isso é apenas um sintoma de outro problema? (pergunta a toda a universidade:“Porquê?”)
• Porque o departamento demora uma eternidade a atingir um consenso” (.......)
– Nunca mais saímos daqui!
14Engenharia de Requisitos - Universidade da Madeira
Como definir o âmbito do problema
• Dificuldade:– Cada problema pode ser visto como um sintoma de outro problema maior
– Podemos andar à procura de causas eternamente!
• Abordagem (perguntas que nos devemos fazer a nós mesmos):– Há alguma expectativa razoável sobre como este problema poderá ser resolvido?
• (independentemente do problema maior?)
– Há alguma expectativa razoável sobre se resolver este problema irá ajudar?• (...sem também resolver o problema maior?)
– Isto é um problema que os stakeholders queiram ver resolvido?• Os “peritos locais” acham que este problema é o problema que vale a pena ser resolvido?
– Isto é um problema que alguém nos irá pagar para o resolver?• Dica: um estudo de viabilidade deve permitir quantificar o retorno sobre o investimento
15Engenharia de Requisitos - Universidade da Madeira
Decidindo o âmbito II
• Decidindo o âmbito da solução– Vamos supôr que decidimos que “o atraso a processar as listas de livros dos
professores” é o nível certo do problema a resolver.• “Então vamos automatizar o formulário de submissão de livros!”
– Mas já que estamos com a “mão na massa”...• “Seria útil se automatizássemos também a submissão de pedidos de livros aos editores”
– ... E também já agora...• “Devíamos automatizar também a gestão dos inventórios de livros, para que se possa
rapidamente aferir os níveis de stocks antes de encomendar mais livros”
– ... E nesse caso...• “Poderíamos já agora automatizar os arquivos dos livros dos anos anteriores para podermos
prever a procura de livros!”
– E portanto:• “Também faria sentido fornecer um sistema de troca de livros usados pois isso tem um
enorme efeito na procura por novos livros!”
– E ainda... Ups pera lá, isto vai custar milhões de Euros!
16Engenharia de Requisitos - Universidade da Madeira
Como definir o âmbito da solução
• Dificuldade:– Podíamos criar tecnologias para o problema eternamente– É difícil decidir quando podemos parar de acrescentar features
• Abordagem (para um conjunto de alternativas possíveis):– Há alguma expectativa razoável sobre se uma alternativa poderá ser implementada?
• (...independentemente de todas as outras opções?)
– Há alguma expectativa razoável sobre se implementar a alternativa irá resolver oproblema original?
• (sem também ser necessário resolver outros aspectos do problema?)
– A solução é algo que satisfará os stakeholders?• (os peritos locais pensam que irão utilizar todas aquelas funções?)
– A solução é algo que alguém nos irá pagar para a construir?• Um estudo de viabilidade poderá quantificar o retorno sobre o investimento para cada uma
das alternativas em causa
17Engenharia de Requisitos - Universidade da Madeira
Abordagens baseadas em objectivos
• Abordagem– Focar no porquê dos sistemas serem construídos
– Exprimir o “porquê” como um conjunto de objectivos dos stakeholders
– Usar refinamento dos objectivos para chegar a requisitos específicos
– Análise de objectivos
– Evolução de objectivos
– Hierarquias de objectivos mostram refinamentos e alternativas
• Vantagens– Razoavelmente intuitiva
– A declaração explícita dos objectivos fornece uma base sólida para a resolução deconflitos
• Desvantagens– Captura uma imagem estática - e se os objectivos mudarem ao longo do tempo?
18Engenharia de Requisitos - Universidade da Madeira
Exemplo de elaboração de objectivos
Planeamento de decisãocrucial tem de ser feito
Decisão tomada pordiscussão via email
Decisão tomada viadiscussão presencial
Agenda tem de ser feita Reunião marcada Reunião realizada
Reunião requisitada Data e hora marcadas Pessoal conhece osdetalhes
Lista de pessoal obtida Material audiovisualdefinido
19Engenharia de Requisitos - Universidade da Madeira
Análise de objectivos
• Elaboração de objectivos– “Porquês?” exploram objectivos de alto nível (contexto)– “Comos?” exploram objectivos de baixo nível (operações)– “De que outra maneira?”s exploram alternativas
• Relações entre objectivos– Um objectivo ajuda outro (+)– Um objectivo fere a concretização de outro (–)– Um objectivo cria outro (++)
• A concretização de um objectivo garante a concretização de outro
– Um objectivo impede outro (––)• A concretização de um objectivo impede a concretização de outro
– Ordem de precedência: quando é necessário atingir os objectivos numa dada ordem
• Análise de obstáculos– Pode este objectivo ser obstruído, e se sim, como?– Quais as consequências de obstruí-lo?
20Engenharia de Requisitos - Universidade da Madeira
Softgoals
• Alguns objectivos poderão nunca ser totalmente satisfeitos
• Exº para um sistema de comboios:
22Engenharia de Requisitos - Universidade da Madeira
Cenários
• Cenários– Sequência específica de interacções entre actor e sistema
– Tendem a ser curtos (exº entre 3 a 8 passos)
– Podem ser positivos (i.é, comportamento requerido) ou negativos (i.é, uma interacçãoindesejada)
– Podem ser indicativos (descrever o sistema actual) ou optativos (como devem ser)
• Vantagens– Muito naturais: os stakeholders tendem a utilizá-los facilmente e espontaneamente
– Cenários curtos são muito bons para ilustrar rapidamente interacções específicas
• Desvantagens– Falta de estrutura: são necessários casos de utilização ou modelos de tarefas para
fornecer uma visão de alto nível
23Engenharia de Requisitos - Universidade da Madeira
Exemplo de Cenário
*Exemplo por Ian Sommerville.
25Engenharia de Requisitos - Universidade da Madeira
Casos de Utilização
• O que são?– Cada forma diferente de interagir com o sistema é um caso de utilização
– Descrição de um conjunto de cenários possíveis com um propósito comum
– Tipicamente escritos em linguagem natural
– Apenas a interacção com o sistema é descrita: nenhuma descrição interna
• Relações entre casos– “extends” e “uses”
• Vantagens e desvantagens– Caracterização detalhada de todas as possíveis interacções com o sistema
– Ajudam a determinar a fronteira e âmbito do sistema
– Não capturam conhecimento do domínio da aplicação
– Não devem ser confundidos com uma especificação completa do sistema
27Engenharia de Requisitos - Universidade da Madeira
Estudos de viabilidade
• Objectivos– Descobrir se um projecto de desenvolvimento de software pode ser feito
• É possível?
• Pode ser justificável?
– Sugerir alternativas possíveis
– Fornecer aos gestores informação suficiente para saber:• Se o projecto pode ser realizado
• Se o produto final irá ser benéfico para os utilizadores
• Quais são as alternativas (para que uma selecção seja feita em fases posteriores)
• Se existe uma alternativa preferível
• Um estudo de viabilidade é uma actividade orientada à gestão– Após o estudo, a gestão toma a decisão de avançar ou não com o projecto
– É necessário examinar o problema no contexto mais amplo de toda a estratégia denegócio
28Engenharia de Requisitos - Universidade da Madeira
O conteúdo do estudo de viabilidade
• Itens a ser estudados no estudo de viabilidade:– O sistema organizacional actual
• Utilizadores, políticas, funções, objectivos, ...
– Problemas com o sistema actual• Inconsistências, funcionalidades inadequadas, desempenho, ...
– Objectivos e novos requisitos para o novo sistema• Que problemas necessitam ser resolvidos?• O que precisa ser alterado?
– Restrições• Incluindo requisitos não-funcionais
– Alternativas possíveis• “Manter o sistema actual” deve ser sempre considerado uma alternativa possível• Considerar também processos de negócio diferentes para a resolução dos problemas
– Vantagens e desvantagens das alternativas
• Itens a concluir:– Viabilidade do projecto– Alternativa preferida
29Engenharia de Requisitos - Universidade da Madeira
Quatro tipos de viabilidade
• Viabilidade Técnica– O projecto é viável, dada a tecnologia
actual? Quanto risco técnico se corre?
– A tecnologia existe ou está disponível?• Disponível localmente?
• Pode ser obtida?
• Será compatível com outros sistemas?
• Viabilidade Económica– O projecto é viável, dadas as restrições
sobre os recursos?
– Que benefícios trará o novo sistema?• Benefícios tangíveis e não-tangíveis
• Devem ser quantificados!
– Quais os custos de desnvolvimento eoperacionais?
– Os benefícios valem os custos?
• Viabilidade Temporal– É possível construir o sistema em tempo
útil?• Existem restrições ao planeamento?
• As restrições podem ser respeitadas?
• Viabilidade Operacional– Aspectos sociais e humanos
– Itens internos• Recursos humanos disponíveis?
• Objecções laborais prováveis?
• Resistência da gestão?
• Conflitos organizacionais e políticas?
– Itens externos• Aceitação social?
• Aspectos legais e regulaçõesgovernamentais?
30Engenharia de Requisitos - Universidade da Madeira
Benefícios e custos
• Benefícios tangíveis– Fáceis de calcular como valores $$$
– Exemplos:• Aumento nas vendas
• Reduções de custos / erros
• Aumento de eficiência
• Aumento da margem de venda
• Uso do tempo do pessoal mais eficiente
• Benefícios intangíveis– Difíceis de quantificar
• Mas podem ser mais importantes!
• Analistas ajudam a estimar os valores
– Exemplos• Aumento da flexibilidade das operações
• Aumento da qualidade dosprodutos/serviços
• Melhoria das relações com os clientes
• Aumento da moral
• Custos de desenvolvimento– Custos de desenvolvimento e aquisições
• Custo da equipa de desenvolvimento• Taxas de consultores• Software utilizado (comprar ou construir?)• Hardware (o que comprar / alugar?)• Instalações (escritórios, electricidade,
comunicações, ...)
– Custos de instalação e conversão• Instalando o sistema, convertendo
ficheiros, ...
• Custos operacionais– Manutenção do sistema
• Hardware (reparações, fornecimentos, ...)• Software (licenças e contratos)• Instalações
– Pessoal• Operação (entrada de dados, backups)• Suporte (ao utilizador, manutenção,
fornecedores, ...)• Custos de formação contínua
31Engenharia de Requisitos - Universidade da Madeira
Analisando custos vs. benefícios
• Identificar custos e benefícios– Tangíveis e intangíveis, pontuais e recorrentes
– Atribuir valores aos custos e benefícios
• Determinar o fluxo de caixa– Projectar os custos e os benefícios ao longo do tempo (exº 3-5 anos)
– Calcular o valor líquido presente para todos os futuros custos/benefícios• Consiste em determinar os futuros custos/benefícios do projecto em termos do valor
monetário actual
• Um Euro ganho hoje vale mais do que um potencial Euro ganho no próximo ano
• Realizar uma análise de custo/benefício– Calcular o Retorno sobre o Investimento
• Permite a comparação do rentabilidade entre soluções alternativas
– Calcular o ponto de Break-Even• Quanto tempo (em anos) vamos levar a pagar os custos que se foram acumulando
32Engenharia de Requisitos - Universidade da Madeira
Risco e ER
• A gestão do risco é uma actividade sistemática– Requer a atenção da equipa técnica e da equipa de gestão!
– Requer uma visão de alto nível do sistema
– Deve ser uma actividade continuada
• Existem técnicas apropriadas para identificar e aferir o risco– Exº: análise de árvore de falhas
– Exº: matriz de verificação do risco
• Risco e engenharia de requisitos– A análise do risco pode revelar novos requisitos
• (especialmente em aplicações de segurança críticas)
– A análise do risco pode revelar ameaças à viabilidade
– A análise do risco ajuda à tomada de decisão apropriada, por parte dos gestores
33Engenharia de Requisitos - Universidade da Madeira
Risco - Conceitos-chave
• Acerca do risco– Risco é a “possibilidade de sofrer perdas”
– O risco por si só não é mau, o essencial é progredir
– O desafio é gerir a quantidade de risco
• Duas partes:– Verificação do risco
– Controlo do risco
• Conceitos úteis:– Para cada risco: Exposição ao Risco
– Para cada acção de mitigação: