Elicitação e Análise

Disciplina Projeto de
Interface com o
Usuário.
Professor: Wilker Bueno
Curso: Análise e Desenvolvimento de Sistemas

Professor Wilker Bueno
2
05/05/2014
O processo do design da
interação
O que
Elicitação e
Analise?

3
28/04/2014
Elicitação e Analise
De Requisitos
Definição:
No âmbito da engenharia, um requisito consiste
da definição documentada de uma propriedade ou
comportamento que um produto ou serviço particular
deve atender.
Na abordagem clássica de engenharia, conjuntos de
requisitos são tipicamente utilizados como informações
fundamentais para a fase de projeto de um produto
ou serviço, especificando as propriedades e funções
necessárias (ou desejáveis) a serem consideradas no
desenvolvimento do projeto em questão.

4
28/04/2014
De Requisitos
Definição:
O conceito de requisito é também utilizado
formalmente na ciência de computação,
engenharia de software e engenharia de
sistemas, referindo-se à definição de uma
característica, atributo, habilidade ou
qualidade que um sistema (ou
qualquer um de seus módulos e sub-
rotinas) deve necessariamente prover para
ser útil a seus usuários;

5
28/04/2014
De Requisitos
Objetivos:

Obter informações sobre o domínio da
aplicação que está sendo desenvolvida;

Definir os serviços que o sistema deve
oferecer;

Planejar o desempenho do
sistema; e

Documentar as restrições
impostas pelo hardware.

6
28/04/2014
De Requisitos
Elicitar significa descobrir,
tornar explícito, obter o
máximo de informações
para o conhecimento do
problema em questão.
Cabe à elicitação a tarefa de identificar os fatos
que compõem os requisitos do Sistema, de forma
a prover o mais correto e mais completo
entendimento do que é demandado do software.

7
28/04/2014
De Requisitos
A elicitação de requisitos visa
identificar e descrever os requisitos
de um software a ser desenvolvido.
O processo para a elicitação de
requisitos prevê primeiramente a
identificação dos objetivos gerais do
software, informações sobre os
problemas atuais existentes e por fim
as necessidades que devem ser
endereçadas pelo software.

8
28/04/2014
De Requisitos
O processo de elicitação e análise de requisitos
1º Descoberta
de Requisitos
2º Classificação e
Organização
de Requisitos
3º Priorização e
Negociação
de Requisitos
4º Especificação
de Requisitos
Elicitação e análise de requisitos é um processo iterativo que pode ser representado como
uma espiral de atividades - descoberta de requisitos, classificação e organização de
requisitos, negociação de requisitos e documentação de requisitos.

9
28/04/2014
De Requisitos
Atividades do processo de elicitação e análise de requisitos
1º Descoberta
de Requisitos
Essa é a atividade de
interação com os stakeholders
do sistema para descobrir
seus requisitos. Os requisitos
de domínio dos stakeholders
e da documentação também
são descobertos durante essa
atividade.

10
28/04/2014
De Requisitos
Essa atividade toma a coleção de requisitos não
estruturados, agrupa requisitos relacionados e
os organiza em grupos coerentes. A forma mais
comum de agrupar os requisitos é o uso de um
modelo de arquitetura do sistema para
identificar subsistemas e associar requisitos a
cada subsistema.
2º Classificação e
Organização
de Requisitos

11
28/04/2014
De Requisitos
Inevitavelmente, quando os vários stakeholders
estão envolvidos, os requisitos entram em conflito.
Essa atividade está relacionada com a priorização
de requisitos e em encontrar e resolver os conflitos
por meio da negociação de requisitos.
Normalmente, os takeholders precisam se
encontrar para resolver as diferenças e chegar a
um acordo sobre os requisitos.
3º Priorização e
Negociação
de Requisitos

12
28/04/2014
De Requisitos
Os requisitos são
documentados e
inseridos no próximo
ciclo da espiral.
Documentos formais ou
informais de requisitos
podem ser produzidos.
4º Especificação
de Requisitos

13
28/04/2014
Elicitação e Análise De Requisitos
Dificuldades no processo de elicitação e compreensão dos requisitos
1. Exceto em termos gerais, os stakeholders
costumam não saber o que querem de um sistema
computacional; eles podem achar difícil articular o
que querem que o sistema faça, e, como não sabem
o que é viável e o que não é, podem fazer exigências
inviáveis.
2. Naturalmente, os stakeholders expressam
requisitos em seus próprios termos e com o
conhecimento implícito de seu próprio trabalho.
Engenheiros de requisitos, sem experiência no
domínio do cliente, podem não entender esses

14
28/04/2014
Dificuldades no processo de elicitação e compreensão dos requisitos
3. Diferentes stakeholders têm requisitos diferentes e podem
expressar elas de várias maneiras. Engenheiros de requisitos
precisam descobrir todas as potenciais fontes de requisitos e
descobrir as semelhanças e conflitos.
4. Fatores políticos podem influenciar os requisitos de um
sistema. Os gerentes podem exigir requisitos específicos,
porque estes lhes permitirão aumentar sua influência na
organização.
5. O ambiente econômico e empresarial no qual a análise
ocorre é dinâmico. É inevitável que ocorram mudanças
durante o processo análise. A importância dos requisitos
específicos pode mudar. Novos requisitos podem surgir a
partir de novos stakeholders que não foram inicialmente

15
28/04/2014
Técnicas para elicitação de requisitos

Descoberta de
Requisitos

Entrevistas

Entrevistas abertas

Entrevistas fechadas

Cenários

Casos de Uso

Etnografia

16
28/04/2014
Descoberta de Requisitos
A descoberta de
requisitos (às vezes
chamada elicitação de
requisitos) é o processo
de reunir informações
sobre o sistema
requerido e os sistemas
existentes e separar
dessas informações os
requisitos do usuário e
de sistema.
Fontes de informação durante a
fase de descoberta de requisitos
incluem documentação,
stakeholders do sistema e
especificações de sistemas
similares. Você interage com os
stakeholders por meio da
observação e de entrevistas e
pode usar cenários e protótipos
para ajudar os stakeholders a
compreender o que o sistema
vai ser .

17
28/04/2014
Entrevistas
Importante:
* Entrevistadores devem estar de “cabeça aberta” e
não fazer a entrevista com noções pré concebidas
sobre o que é necessário;
* Informar aos stakeholders o ponto inicial da discussão.
Isto pode ser uma questão, uma proposta de requisitos ou
um sistema existente; e
* Entrevistadores devem estar cientes da política
organizacional - muitos requisitos reais podem não
serem discutidos devido as implicações políticas;

18
28/04/2014
Os stakeholders variam
desde os usuários finais,
passando pelos gerentes do
sistema até stakeholders
externos, como reguladores,
que certificam a
aceitabilidade do sistema. Por
exemplo, os stakeholders do
sistema de informação de um
sistema de informação da
saúde mental dos pacientes

19
28/04/2014
1. Os pacientes cujas informações estão registradas no sistema.
2. Os médicos responsáveis pela avaliação e tratamento dos pacientes.
3. Os enfermeiros que, alinhados com os médicos, coordenam as
consultas e administram tratamentos.
4. As (os) recepcionistas dos médicos, que gerenciam as consultas dos
pacientes.
5. A equipe de TI, responsável pela instalação e manutenção do
sistema.
6. Um gerente de ética médica, que deve garantir que o sistema atenda
às diretrizes éticas atuais no atendimento ao paciente.
7. Gerentes de saúde, que obtêm informações de gerenciamento a partir
do sistema.
8. A equipe de registros médicos, responsável por garantir que as
informações do sistema sejam mantidas e preservadas, e que os
procedimentos de manutenção dos registros sejam devidamente

20
28/04/2014
Entrevistas
Entrevistas formais ou
informais com os stakeholders
do sistema são parte da
maioria dos processos de
engenharia de requisitos.
Nessas entrevistas, a equipe
de engenharia de requisitos
questiona os stakeholders
sobre o sistema que usam no
momento e sobre o sistema
que será desenvolvido.
Requisitos surgem a partir das
respostas a essas perguntas.
As entrevistas podem ser de
dois tipos:
1. Entrevistas fechadas, em que o
stakeholder responde a um
conjunto predefinido de perguntas.
2. Entrevistas abertas, em que
não existe uma agenda
predefinida. A equipe de
engenharia de requisitos explora
uma série de questões com os
stakeholders do sistema e, assim,
desenvolve uma melhor
compreensão de suas
necessidades.

21
28/04/2014
Entrevistas
1. Todos os especialistas em
aplicações usam
terminologias e jargões
específicos para um domínio.
Para eles, é impossível
discutir os requisitos de
domínio sem essa
terminologia. Eles
normalmente usam a
terminologia de forma
precisa e sutil, o que
dificulta a compreensão dos
engenheiros de requisitos.
2. O conhecimento de domínio é
tão familiar aos stakeholders que
eles têm dificuldade de explicá-lo,
ou pensam que é tão fundamental
que não vale a pena mencionar.
Por exemplo, para um
bibliotecário, não é necessário
dizer que todas as aquisições
são catalogadas antes de serem
adicionadas à biblioteca. No
entanto, isso pode não ser óbvio
para o entrevistador, e acaba não
sendo levado em conta nos
Pode ser difícil elicitar conhecimento do domínio por meio de entrevistas por
duas razões:

22
28/04/2014
Entrevistas
1. Eles estão abertos a novas ideias, evitam
ideias preconcebidas sobre os requisitos e
estão dispostos a ouvir os stakeholders.
Mesmo que o stakeholder apresente
requisitos-surpresa, eles estão dispostos a
mudar de ideia sobre o sistema.
2. Eles estimulam o entrevistado a participar
de discussões com uma questão-trampolim,
uma proposta de requisitos ou trabalhando
em um conjunto em um protótipo do sistema.
É improvável que dizer às pessoas “diga-me
o que quiser” resulte em informações úteis. É
muito mais fácil falar em um contexto definido
do que em termos gerais.
Entrevistadores eficazes
têm duas características:

23
28/04/2014
Entrevistas
Vantagens:
- Contato direto com o
usuário e validação
imediata.
Desvantagens:
- Conhecimento tácito e
diferenças de cultura.
Entrevistas fechadas. O
engenheiro de requisitos
busca respostas para um
conjunto de questões pré
definidas.
Entrevistas abertas. Não há
uma agenda pré-definida e o
engenheiro de requisitos
discute, de
forma aberta, o que o
stakeholders quer do sistema.
O engenheiro de requisitos ou analista discute o sistema com
diferentes stakeholders e obtêm um entendimento dos requisitos.

24
28/04/2014
Entrevistas
Importante:
* Entrevistadores devem estar de “cabeça aberta” e
não fazer a entrevista com noções pré concebidas
sobre o que é necessário;
* Informar aos stakeholders o ponto inicial da discussão.
Isto pode ser uma questão, uma proposta de requisitos ou
um sistema existente; e
* Entrevistadores devem estar cientes da política
organizacional muitos requisitos reais podem não serem
discutidos devido as implicações políticas;

25
28/04/2014
Cenários
Emsua forma mais geral, umcenário pode incluir:
1. Uma descrição do que o sistema e os usuários
esperam quando o cenário de iniciar.
2. Uma descrição do fluxo normal de eventos no
cenário.
3. Uma descrição do que pode dar errado e como isso é
tratado.
4. Informações sobre outras atividades que podem
acontecerao mesmo tempo.
5. Uma descrição do estado do sistema quando o
cenário acaba.

26
28/04/2014
Cenários (Exemplo)
Suposição:
O paciente é atendido em
uma clínica médica por uma
recepcionista; ela gera um
registro no sistema e coleta
suas informações pessoais
(nome, endereço, idade etc.)
Uma enfermeira é conectada
ao sistema e coleta o
histórico médico do paciente.

27
28/04/2014
Cenários (Exemplo)
Normal:
A enfermeira busca o paciente pelo sobrenome. Se houver mais
de um paciente com o mesmo sobrenome, o nome e a data de
nascimento são usados para identificaro paciente.
A enfermeira escolhe a opção do menu para adicionaro histórico
médico.
A enfermeira segue, então, uma série de prompts do
sistema para inserir informações sobre consultas em outros
locais, os problemas de saúde mental (entrada de texto
livre), condições médicas (enfermeira seleciona condições do
menu), medicação atual (selecionado no menu), alergias (texto
livre) e informações da vida doméstica (formulário).

28
28/04/2014
Cenários (Exemplo)
Oque pode darerrado?
O prontuário do paciente não existe ou não pôde ser encontrado.
A enfermeira deve criar um novo registro e registrar as informações pessoais
As condições do paciente ou a medicação em uso não estão inscritas no menu.
A enfermeira deve escolher a opção ‘outros’ e inserir texto livre com descrição da condição/medicação
O paciente não pode/não fornecerá informações sobre seu histórico médico.
A enfermeira deve inserir um texto livre registrando a incapacidade/relutância do paciente
em fornecer as informações. O sistema deve imprimir o formulário padrão de exclusão afirmando
que a falta de informação pode significar que o tratamento será limitado ou postergado.
Este deverá ser assinado e entregue ao paciente.
Outras
atividades
:
Enquanto a informação
está sendo inserida, o registro
pode ser consultado,
mas não editado por
outros agentes
Estado
do
sistema
na
O usuário está conectado.
O prontuário do paciente,
incluindo seu histórico médico,
é inserido no banco de dados
e um registro é adicionado ao
log do sistema, mostrando o
tempo de início e fim da sessão
e a enfermeira envolvida

29
28/04/2014

30
28/04/2014
Caso de Uso
Característica fundamental
da linguagemUML;
- Identifica os atores
envolvidos em uma interação e
dá nome ao tipo de interação;
- Representa todas as possíveis
interações que serão descritas
nos requisitos do sistema;
- Atores, que podem ser
pessoas ou outros sistemas,
são representados como
figuras ‘palito’;

31
28/04/2014
Caso de Uso
- Cada classe de interação é
representada poruma elipse;
- Identificam as interações
individuais entre o sistema e
seus usuários ou outros sistemas;
- Cada caso de uso deve ser
documentado com uma descrição
textual; e
- É uma técnica eficaz para
elicitar requisitos dos
stakeholders que vão interagir
diretamente como sistema.

32
28/04/2014
Caso de Uso (Exemplo)
Uma breve descrição do caso de uso Agendar
consultaAgendar a consulta permite que dois ou
mais médicos de consultórios diferentes
possam ler o mesmo registro ao mesmo
tempo . Um médico deve escolher, em
um menu de lista de médicos on-line, as
pessoas envolvidas. O prontuário do
paciente é então exibido em suas telas,
mas apenas o primeiro médico pode editar
o registro. Além disso, uma janela de
mensagens de texto é criada para ajudar
a coordenar as ações. Supõe que uma
conferência telefônica para comunicação
por voz será estabelecida separadamente.

33
28/04/2014
Etnografia
É uma técnica de
observação que pode ser
usada para compreender
os processos operacionais
e ajudar a extrair os
requisitos de apoio para
esses processos. Um
analista faz uma imersão
no ambiente de trabalho
em que o sistema será
usado.

34
28/04/2014
Etnografia
O trabalho do dia a dia é observado e são feitas
anotações sobre as tarefas reais em que os
participantes estão envolvidos. O valor da etnografia é
que ela ajuda a descobrir requisitos implícitos do
sistema que refletem as formas reais com que as
pessoas trabalham em vez de refletir processos
formais definidos pela organização.

35
28/04/2014
Considerações finais

Os requisitos para um sistema de software estabelecem o que o
sistema deve fazer e define as restrições sobre seu funcionamento e
implementação .

Os requisitos funcionais são declarações dos serviços que o
sistema deve fornecer ou descrições de como alguns
processamentos devem ser efetuados.

Muitas vezes, os requisitos não funcionais restringem o sistema
que está sendo desenvolvido e o processo de desenvolvimento que
está sendo usado. Estes podem ser os requisitos de produto,
requisitos organizacionais ou requisitos externos. Eles costumam se
relacionar com as propriedades emergentes do sistema e, portanto,
aplicam se ao sistema como um todo.

O documento de requisitos de software é uma declaração acordada
dos requisitos do sistema. Deve ser organizado para que ambos – os
clientes do sistema e os desenvolvedores de software possam usá-lo .

36
28/04/2014
Considerações finais

O processo de engenharia de requisitos inclui um estudo da
viabilidade, elicitação e análise de requisitos,especificação de
requisitos, validação e gerenciamento de requisitos.

Elicitação e análise de requisitos é um processo iterativo que
pode ser representado como uma espiral de atividades
descoberta de requisitos, classificação e organização de
requisitos, negociação de requisitos e documentação de requisitos.

A validação de requisitos é o processo de verificação da
validade, consistência e completude, realismo e verificabilidade
dos requisitos.

Mudanças organizacionais, mudanças nos negócios e mudanças
e técnicas, inevitavelmente geram mudanças nos requisitos para
um sistema de software. O gerenciamento de requisitos é o
processo de gerenciamento e controle dessas mudanças.

Elicitação e Análise

Mais conteúdo relacionado

Mais procurados

Semelhante a Elicitação e Análise

Mais de Wilker Bueno de Freitas Rosa

Elicitação e Análise