Engenharia de Requisitos - cee.uma.ptcee.uma.pt/edu/er/slides/ER-IniciandoProjectoER.pdf ·...

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]


Agenda

• Stakeholders e fronteiras

• Objectivos e cenários

• Viabilidade e risco


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


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.


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!


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


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


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.


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


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


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


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!


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


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!


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


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?


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


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?


Softgoals

• Alguns objectivos poderão nunca ser totalmente satisfeitos

• Exº para um sistema de comboios:


Softgoals como critério de selecção


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


Exemplo de Cenário

*Exemplo por Ian Sommerville.


Exemplo de Cenário


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


Exemplo de casos de utilização


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


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


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?


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


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


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


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:

Engenharia de Requisitos - cee.uma.ptcee.uma.pt/edu/er/slides/ER-IniciandoProjectoER.pdf ·...

Documents

Transcript of Engenharia de Requisitos - cee.uma.ptcee.uma.pt/edu/er/slides/ER-IniciandoProjectoER.pdf ·...