Vous êtes sur la page 1sur 28

Universidade Federal Rural do Semi-rido

Prof. Jomia Leilane Gomes de Medeiros Martins


Disciplina: Processos e Requisitos de Software

Elicitao de Requisitos
Tcnicas de Elicitao

leilane.gomes@ufersa.edu.br
O Processo de Engenharia de Requisitos
Engenharia de Requisitos

Quatro fases:

Estudo de viabilidade
Elicitao e anlise de requisitos
Validao dos requisitos
Gerenciamento dos requisitos

Resultado: DOCUMENTO DE REQUISITOS


Estudo de viabilidade

Um estudo de viabilidade decide se vale a pena ou no gastar tempo


e esforo com sistema proposto.

um estudo breve e focalizado que verifica:


Se o sistema contribui para os objetivos da organizao;
Se o sistema pode ser implementado usando tecnologia atual e dentro do
oramento;
Se o sistema pode ser integrado a outros.
Elicitao e Anlise de Requisitos

Reunir informaes sobre o sistema proposto e os existentes


Fonte: documentos, organizao, especificaes existentes, observaes, entrevistas
etc.
Engenheiros de software, clientes e usurios finais do sistema e outros
envolvidos (stakeholders) trabalham para aprender
Sobre o domnio da aplicao;
Quais servios/funcionalidades o sistema deve fornecer;
O desempenho esperado;
As restries de hardware, do ambiente, do negcio;
...
Elicitao e Anlise de Requisitos
Dificuldades:
Stakeholders no sabem o que querem do sistema e no expressam o que
querem;

Stakeholders expressam requisitos naturalmente usando seus prprios termos


(requisitos de domnio);

Diferentes stakeholders tm diferentes requisitos;

Fatores polticos podem influenciar (mais poder para um gerente);

Ambiente dinmico muda constantemente. Novos requisitos podem surgir de


novos stakeholders.
Elicitao e Anlise de Requisitos

Atividades de processo de elicitao:


Obteno de requisitos (coleta de dados): processo de iterao com os
stakehokders no sistema para coletar seus requisitos.
Classificao e organizao de requisitos: esta atividade envolve a coleo
dos requisitos relacionados e os agrupa em conjuntos coerentes.
Priorizao e negociao de requisitos: vrios stakehokders tendem a ter
requisitos conflitantes. Esta atividade resoluo de conflitos de requisitos
por meio de negociao.
Documentao de requisitos: os requisitos so formalizados e
documentados.
Obteno dos requisitos: Stakeholders para um sistema bancrio

Clientes atuais do banco


Representantes de outros bancos (acordos para integrao entre sistemas)
Gerentes de agncias (gerenciamento do sistema)
Pessoal de atendimento nas agncias envolvidas
Administradores de banco de dados
Gerentes de proteo bancria (segurana)
Departamento de marketing
Engenheiros de manuteno de hardware e software
Reguladores de bancos (conformidade com as leis)
Tcnicas de Elicitao

Entrevistas
Questionrios
Casos de Uso
Jogo de Funes
Reunies
Brainstorming
Workshop de Requisitos JAD (Joint Application Design)
Cenrios
Entrevistas
A equipe de engenharia de requisitos formula questes para os
stakeholders sobre o sitema que eles usam e o sistema a ser
desenvolvido.

Os requisitos so derivados das respostas a essas questes.

Objetivo
Entender os problemas reais e solues potenciais das perspectivas
dos usurios, clientes, e outros stakeholders
Entrevistas: so eficientes??
Entrevistas

A entrevista no uma tcnica eficiente para elicitao de


conhecimentos sobre os requisitos e as restries organizacionais,
pois existem relacionamentos sutis de poder e influncia entre os
stakeholders na organizao.
Entrevistas
Quem so o cliente e o usurio?
Possuem necessidades diferentes?
Quais so suas
Capacidades
Ambientes, etc.
Qual o problema?
Como resolvido atualmente?
Qual a razo para resolv-lo?
Qual o valor de uma soluo bem-sucedida?
Onde mais uma soluo pode ser encontrada?
Entrevistas

Quatro tipos de questes so importantes em entrevistas:


- Sobre o usurio: caractersticas dos usurios

- Sobre o processo: o modo como as pessoas executam as tarefas

- Sobre o produto: funcionalidades e caractersticas do produto final.


Exemplo: um relatrio, uma consulta etc.

- Meta-perguntas: uma tcnica onde se faz perguntas a partir de outra


pergunta.
Entrevistas

Usurio:
Quem o cliente?
Quem o usurio?
Suas necessidades so diferentes?
Quais so suas formaes, habilidades, ambientes?
Entrevistas
Processo:
Qual o problema?
Como resolvido atualmente?
Qual a razo para resolver o problema?
Existe outra soluo para este problema?
Qual o valor de uma soluo bem-sucedida?
Entrevistas
Produto:
Que problema esse produto resolve?
Que problemas de negcios esse produto poder ocasionar?
Que riscos podero existir para o usurio?
Que ambiente o produto encontrar?
Quais so as suas expectativas em relao usabilidade (facilidade de uso)?
Quais so as suas expectativas em relao confiabilidade?
Que desempenho/preciso exigido?
Entrevistas

Meta-perguntas:
Estou fazendo muitas perguntas?
Minhas perguntas parecem relevantes?
Voc a pessoa certa para responder a essas perguntas?
As suas respostas so requisitos?
Posso fazer mais perguntas depois?
Voc aceitaria participar de uma reviso de requisitos?
H algo mais que eu poderia perguntar a voc?
Questionrios
Aplicabilidade a mercados especficos
Onde perguntas so bem definidas
Hipteses
Perguntas relevantes podem ser decididas antecipadamente
Leitor ouve da maneira desejada
Suprime o que bom sobre anlise
teis aps uma entrevista inicial
Acesso a um grande nmero de pessoas
Vantagens:
padronizao de perguntas
possibilidade de tratamento estatstico das respostas
Desvantagens:
limitao do universo de respostas
pouca interao (impessoalidade tcnica)
Cenrios

A elicitao baseada em cenrios pode ser realizada informalmente.

Os engenheiros de requisitos trabalham com os stakeholders para


identificar cenrios e captar os detalhes desses cenrios.

Podem ser escritos na forma de textos, diagramas, imagens de


computador.

Exemplo: o usurio de um sistema de biblioteca pode usar o sistema.


Casos de Uso
Tcnica baseada em cenrios.
Em sua forma mais simples, o caso de uso identifica o tipo da interao
e os usurios envolvidos.
Discuta com o cliente o que o sistema far.
Identique quem interage com o sistema.
Identique que interfaces o sistema ter.
Verifique se no h requisitos faltando.
Verifique que os desenvolvedores entendem os requisites.
Vantagem ter apelo visual dos requisitos mais relevantes do cliente.
Modelo de Casos de Uso
O Modelo de Casos de Uso
Especifica em detalhes requisitos do sistema

Emprega
Atores
Casos de Uso

Cliente
Comprar
Ator
Os atores representam o que interage com o sistema
Representam tudo que necessita trocar informao com o sistema
Como esto fora do sistema: no so descritos em detalhe
algo com comportamento como
uma pessoa (identificada pelo seu papel)
um sistema computacional
uma organizao
Atores so diferentes de usurios:
usurio usa o sistema
ator representa uma certa regra seguida pelo usurio
uma mesma pessoa pode aparecer como instncia de vrios atores Cliente
Caso de Uso

Caso de Uso:
O que deve ser feito pelo sistema
histrias de sucesso e insucesso que suportam o mesmo objetivo Comprar

um conjunto de cenrios relacionados

Cenrio:
uma sequncia especfica de aes e interaes entre atores e sistema
Etnografia

Tcnica de observao que pode ser usada para compreender os


requisitos sociais e organizacionais.
Um analista se insere no ambiente de trabalho onde o sistema ser
usado.
Ele observa o trabalho do dia a dia e anota as tarefas reais nas quais
os participantes esto envolvidos.
Assim os requisitos de software so atingidos por esse contexto.
Jogo de Funes

Engenheiro de requisitos
Assume a funo do usurio ou cliente
Entender o domnio do problema
Cliente
Assume a funo do usurio
Entender os problemas que podem passar
Brainstorming

Tcnica de discusso em grupo que se vale da contribuio espontnea de


ideias por parte de todos os participantes, no intuito de resolver algum
problema ou de conceber um trabalho criativo.
Regras para Brainstorming
Estabelea o objetivo da sesso
Gere quantas idias for possvel
Deixe sua imaginao livre
No admita crticas ou debates
Ajuste e combine as idias
Exerccio

1. Sugira quem podem ser os stakeholders em um sistema de registro


de estudantes de uma Universidade. Explique porque quase
inevitvel que os requisitos de diferentes stakeholders sejam
conflitantes de alguma forma.
2. Usando seu conhecimento de como um caixa eletrnico usado,
desenvolva um conjunto de casos de uso que pode servir como
base para compreenso dos requisitos de um sistema de caixa
eletrnico.
3. Pesquisar sobre o JAD.
4. Ler o captulo 7 do Sommerville.
FIM
29/03/2017

Vous aimerez peut-être aussi