6. Identificar Necessidades e Definir Requisitos (Aula Te

1
6. Identificar Necessidades e Definir
Requisitos(Aula Teórica 6 apresentação
adaptada do sítio de Preece et al 2002)

• Uma boa definição de requisitos é essencial para
  vir a disponibilizar um sistema com sucesso.
• A recolha, interpretação e análise de informação
  deve originar um modelo conceptual adequado.
• A seguir 7. Projecto, protótipos e construção
  8. Projecto centrado nos utilizadores (UCEP -
  WISDOM) 9. Avaliação 10. Observar os
  utilizadores.

2
Temas da Aula

• O Quê, Como e Quando (QCQ)?
• O que são Requisitos?
• Funcionais
• Não-Funcionais 1. informação, 2. ambiente
  (físico, social, organizacional, técnico), 3.
  utilizadores, 4. usabilidade ()
• Recolha de Dados / Informação.
• Interpretação e Análise de Dados / Informação.
• Descrição de Tarefas.
• Cenários, casos de uso, casos de uso essenciais
• Análise de Tarefas.
• Análise hierárquica de tarefas, fluxos essenciais
  de tarefas (CTT)

3
O Quê, Como e Quando?

• O Quê
• Compreender, da melhor forma possível, os
  utilizadores, tarefas e contexto.
• Produzir uma definição estável de requisitos.
• Como
• Recolha de dados.
• Análise de dados.
• Expressar como requisitos.
• Este é um processo iterativo.
• Quando
• A definição de requisitos é a fase de
  desenvolvimento onde mais erros são introduzidos.
• Definir correctamente os requisitos é vital.

4
Definir Requisitos

• O que é que os utilizadores querem? O que é que
  eles necessitam?
• Os requisitos necessitam de ser clarificados,
  refinados, completados e re-enquadrados.
• Entrada Talvez um documento de requisitos.
• Saída Requisitos estáveis.
• Porquê definir?
• Os requisitos surgem da compreensão das
  necessidades dos utilizadores.
• Os requisitos podem ser justificados e
  relacionados com os dados.

5
O que são Requisitos?

• Funcionais
• O que o sistema deve fazer.
• No passado, a principal preocupação da equipa de
  desenvolvimento.
• Não-Funcionais
• Informação.
• Ambiente.
• Utilizadores.
• Usabilidade.

6
Requisitos Não-Funcionais

• Informação
• Que tipos de informação vai ser necessário
  guardar?
• Como vai ser guardada (ex. SGBD, ficheiros,
  etc.)?
• Ambiente
• Físico (poeira, barulho, vibração, luz, calor,
  humidade, etc.).
• Social (partilha de ficheiros e ecrãs, trabalho à
  distância, trabalho individual, privacidade).
• Organizacional (hierarquia, suporte aos
  utilizadores, estrutura de comunicação e
  infra-estrutura, disponibilidade de formação).
• Técnico (tempo de resposta do sistema, ocupação
  da memória).

7
Requisitos Não-Funcionais

• Utilizadores (quem são?)
• Características capacidades, passado e atitude
  perantes os computadores.
• Usos do sistema novato, perito, casual e
  frequente.
• Novato passo-a-passo (diálogo), restrito e
  informação clara.
• Perito flexibilidade e acesso/poder.
• Frequente possibilidade de acesso rápido a
  certas funcionalidades.
• Casual instruções claras.
• Usabilidade
• Aprendizagem
• Capacidade
• Flexibilidade
• Atitude

Requisitos do utilizador e de usabilidade são
diferentes!
8
Técnicas para Recolha de Dados

• Questionários
• Entrevistas
• Reuniões (brainstorming, focus groups, )
• Observação dos utilizadores no seu ambiente
  natural
• Estudo de documentação existente

9
Técnicas qual ou quais Utilizar?

• As várias técnicas diferem em dois aspectos
• Tempo, nível de detalhe e risco associado com os
  resultados.
• Conhecimento que o analista necessita.
• A escolha da técnica depende também do tipo de
  tarefa a estudar
• Passos sequenciais ou séries de sub-tarefas
  sobrepostas?
• Grande ou pequeno volume de informação
  informação complexa ou simples?
• Tarefa direccionada para um leigo ou para um
  utilizador com vastos conhecimentos?

10
Problemas com a Recolha de Dados

• Identificar e envolver parceiros (stakeholders)
  utilizadores, gestores, programadores,
  representantes dos clientes?, representantes dos
  sindicatos?, accionistas?
• Envolver parceiros reuniões, entrevistas,
  estudos no local, colocar parceiros na equipa de
  desenvolvimento.
• Utilizadores reais (e não gestores).

11
Problemas com a Recolha de Dados

• Gestão de requisitos controlo de versões e
  titular dos requisitos.
• Comunicação entre entidades
• Dentro da equipa de desenvolvimento.
• Com o cliente/utilizador.
• Entre utilizadores.
• Conhecimento sobre o domínio distribuído e
  implícito
• Difícil de aprofundar e compreender.
• Articulação do conhecimento (como caminhamos?).
• Disponibilidade das pessoas chave.

12
Problemas com a Recolha de Dados

• Problemas de política dentro da organização
• Domínio de certos parceiros
• Alterações no meio económico e empresarial
• Equilibrar necessidades funcionais e de
  usabilidade

13
Algumas Regras

• Concentrar-se em identificar as necessidades dos
  parceiros.
• Envolver todos os grupos de parceiros.
• Envolver mais do que um representante de cada
  grupo.
• Utilizar uma combinação de técnicas de recolha de
  dados.

14
Algumas Regras

• Suportar o processo com protótipos e descrições
  de tarefas.
• Fazer uma sessão piloto.
• Encontrar uma solução de compromisso entre os
  dados que se recolhem e a análise a efectuar, mas
  antes é necessário definir o que se pretende.
• Considerar as várias formas de registar a
  informação recolhida.

15
Entender os objectivos dos Utilizadores/Clientes
16
Interpretação e Análise dos Dados

• Deve iniciar-se logo após a recolha.
• É importante fazer uma análise inicial antes de
  uma mais profunda.
• Abordagens diferentes realçam diferentes
  elementos (diagramas de classes para sistemas OO
  e diagramas EA para sistemas com muitos dados, )

17
Descrição das Tarefas

• Cenários
• Descrição narrativa informal, simples, natural,
  pessoal e não generalizável.
• Casos de Uso
• Quando há interacção com um sistema.
• Pressupõe-se que há grande interacção com o
  sistema.
• Casos de Uso Essenciais
• Abstractos em relação a detalhes de tecnologia.
• Não se baseiam nos mesmos pressupostos dos Casos
  de Uso.

18
Cenário (Calendário Partilhado)

• The user types in all the names of the meeting
  participants together with some constraints such
  as the length of the meeting, roughly when the
  meeting needs to take place, and possibly where
  it needs to take place. The system then checks
  against the individuals calendars and the
  central departmental calendar and presents the
  user with a series of dates on which everyone is
  free all at the same time. Then the meeting could
  be confirmed and written into peoples calendars.
  Some people, though, will want to be asked before
  the calendar entry is made. Perhaps the system
  could email them automatically and ask that it be
  confirmed before it is written in.

19
Casos de Uso (Calendário Partilhado)

• 1. The user chooses the option to arrange a
  meeting.
• 2. The system prompts user for the names of
  attendees.
• 3. The user types in a list of names.
• 4. The system checks that the list is valid.
• 5. The system prompts the user for meeting
  constraints.
• 6. The user types in meeting constraints.
• 7. The system searches the calendars for a date
  that satisfies the constraints.
• 8. The system displays a list of potential dates.
• 9. The user chooses one of the dates.
• 10. The system writes the meeting into the
  calendar.
• 11. The system emails all the meeting
  participants informing them of them appointment

20
Alternativas (Calendário Partilhado)

• Some alternative courses
• 5. If the list of people is invalid,
• 5.1 The system displays an error message.
• 5.2 The system returns to step 2.
• 8. If no potential dates are found,
• 8.1 The system displays a suitable message.
• 8.2 The system returns to step 5.

21
Diagrama de Casos de Uso(Calendário Partilhado)
22
Casos de Uso Essenciais(Calendário Partilhado)

• Essential Use Case arrangeMeeting
• USER INTENTION SYSTEM RESPONSIBILITYarra
  nge a meeting request meeting
  attendees constraints
• identify meeting attendees constraints
• search calendars for suitable dates
• suggest potential dateschoose preferred
  date
• book meeting

23
Casos de Uso Essenciais e Fluxos de Tarefas
Essenciais
24
Análise de Tarefas

• A descrição de tarefas é normalmente utilizada
  para encontrar novos sistemas ou dispositivos.
• A análise de tarefas é usada essencialmente para
  investigar uma situação existente.
• É importante não focar a atenção em actividades
  superficiais.
• O que é que as pessoas estão a tentar atingir?
• Porque é que estão a tentar atingir?
• Como é que está a decorrer esse processo?
• Há muitas técnicas disponíveis. A mais conhecida
  é a Análise Hierárquica de Tarefas (Hierarchical
  Task Analysis HTA).

25
Análise Hierárquica de Tarefas

• Dividir as tarefas em sub-tarefas e depois em
  sub-sub-tarefas, etc. Estas são agrupadas em
  planos que especificam como é que podem ser
  executadas na prática.
• Concentra-se em acções físicas e observáveis e
  inclui o estudo das acções não relacionadas com
  software ou um dispositivo de interacção.
• Parte-se de um objectivo do utilizador e
  identificam-se as tarefas que permitem atingir
  esse objectivo.
• As tarefas são depois divididas em sub-tarefas.

26
Exemplo de HTA (gráfico)
27
Requisitos ? Modelo Conceptual

• Descrição do sistema proposto em termos de um
  conjunto integrado de ideias e conceitos sobre o
  que este deve fazer, como se deve comportar e que
  aspecto deve ter, que deve ser compreensível
  pelos utilizadores da forma desejada.
• (a description of the proposed system in terms
  of a set of integrated ideas and concepts about
  what it should do, behave and look like, that
  will be understandable by the users in the manner
  intended)
• Projectar (Design, prototyping and
  construction) pressupõe derivar um bom modelo
  conceptual

28
Especificação de Requisitos(UTIL Documento de
Especificação de Requisitos)

• A definição de requisitos (documento de
  especificação de requisitos) deve incluir um
  modelo conceptual?
• A definição de requisitos deve ser neutra em
  relação ao modelo conceptual?
• A definição de requisitos pode ser neutra em
  relação ao modelo conceptual?

29
Sumário

• O Quê, Como e Quando (QCQ)?
• O que são Requisitos?
• Funcionais e Não funcionais
• Recolha de Dados / Informação
• Questionários, Entrevistas, Reuniões de grupos,
  Observação (social, comportamental, ...), Estudo
  de documentação.
• Interpretação e Análise de Dados / Informação.
• Descrição de Tarefas.
• Análise de Tarefas
• Análise hierárquica de tarefas, fluxos essenciais
  de tarefas, Concur Task Trees CTT, goals,
  operations, methods, and selection rules GOMS

30
O que ficou na cabeça

• No final deste capítulo os alunos devem saber
• Como Identificar Necessidades e Definir
  Requisitos.
• Referências Capítulo 7 Preece et al 2002 ver
  também Joel 2001 (Cap.9) e Constantine 2001
  (enviados por correio electrónico).

31
Exercícios Práticos

1. Identificar Necessidades e Definir Requisitos
   (Fase ID da ID-APP) para um sistema de apoio à
   avaliação e atribuição de classificações a alunos
   na FEUP / Ensino Superior.
2. Este sistema deve ser autónomo mas integrado com
   o SiFEUP ...
3. Quem são os utilizadores?
4. Compare a utilização das suas abordagens para a
   fase de ID
5. Cenários e casos de uso
6. Tarefas ou actividades (do planeamento baseado em
   actividades)