IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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)
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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).
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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!
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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?
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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).
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
15
Entender os objectivos dos
Utilizadores/Clientes
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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, …)
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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 people’s 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.»
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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
8.2
The system displays a suitable message.
The system returns to step 5.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
21
Diagrama de Casos de Uso
(Calendário Partilhado)
Arrange a
meeting
Retrieve
contact details
Administrator
Update calendar
entry
Departmental
member
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
22
Casos de Uso Essenciais
(Calendário Partilhado)
Essential Use Case: arrangeMeeting
USER INTENTION
arrange a meeting
SYSTEM RESPONSIBILITY
request meeting attendees &
constraints
identify meeting attendees
& constraints
search calendars for suitable
dates
suggest potential dates
choose preferred date
book meeting
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
23
Casos de Uso Essenciais e
Fluxos de Tarefas Essenciais
User
S ystem
A dd Document
Identify
D oc umen t
Remove Document
As k to R es er v e
D oc umen t
: D oc u me nt Br ow s er
V isualize Document
C hec k if D o c ument
is R es erv ed
<<include>>
Modify Document
Define Document P ermissions
[ Yes ]
User
(from Use Case V iew)
[No ]
Define P eople Interested in
Document
Get Document
Reserve Document
<<resembles>>
Inform D oc umen t is
Alre ady R es er v ed
Spe c ify R es er v ation
C omment
Spe c ify Loc al
D es tinatio n Folder
: Ve rs ion Editor
D ow nload
D oc umen t
P ut Document
Lon g d ela y s c an
hap pen! Prov ide
dow nload feeb ac k .
Sav e D oc ument
to Loc al Folder
Cancel R eservation
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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).
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
25
Análise Hierárquica de Tarefas
• Dividir as tarefas em sub-tarefas e depois em sub-subtarefas, 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.
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
26
Exemplo de HTA (gráfico)
Borrow a
book from the
library
0
plan 0:
do 1-3-4.
If book isn’t on the shelf expected, do 2-3-4.
go to the
library
1
find required
book
2
retrieve book
from shelf
3
take book to
counter
4
plan 2:
do 2.1-2.4-2.5.
If book not identified from information available, do 2.2-2.3-2.4-2.5
access
catalog
2.1
access
search
screen 2.2
enter
search
criteria 2.3
identify
required
2.4
book
note
location
2.5
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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 …
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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?
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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).
João Falcão e Cunha, Miguel B. Gonçalves © 2003
IPC (2003/04) :: Identificar Necessidades e Definir Requisitos
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.
1. Este sistema deve ser autónomo mas integrado com o SiFEUP ...
2. Quem são os utilizadores?
2. Compare a utilização das suas abordagens para a fase
de ID:
1. Cenários e casos de uso
2. Tarefas ou actividades (do planeamento baseado em actividades)
João Falcão e Cunha, Miguel B. Gonçalves © 2003