elicitação e análise

Disciplina Projeto de Interface com

o Usuário.

Professor: Wilker BuenoCurso: 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 AnaliseDe 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


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


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


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


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


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


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



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



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



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 requisitos.


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 consultados.


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



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 incluem:


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 implementados.


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 requisitos.

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, deforma 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

Em sua forma mais geral, um cená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 acontecer ao 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 identificar o paciente.A enfermeira escolhe a opção do menu para adicionar o 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)

O que pode dar errado?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 atividade

s:

Enquanto a informação está sendo inserida, o registro

pode ser consultado,mas não editado por

outros agentes

Estado do

sistema na

conclusão:

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 linguagem UML;

- 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 por uma 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 com o sistema.


32

28/04/2014


Caso de Uso (Exemplo)

Uma breve descrição do caso de uso Agendar consulta

Agendar 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

Technology