A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 2003 1 6. Identificar Necessidades e Definir.

Apresentações semelhantes


Apresentação em tema: "IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 2003 1 6. Identificar Necessidades e Definir."— Transcrição da apresentação:

1 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Entender os objectivos dos Utilizadores/Clientes

16 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 them automatically and ask that it be confirmed before it is written in.»

19 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 s all the meeting participants informing them of them appointment

20 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Alternativas (Calendário Partilhado) Some alternative courses: 5.If the list of people is invalid, 5.1The system displays an error message. 5.2The system returns to step 2. 8.If no potential dates are found, 8.1The system displays a suitable message. 8.2The system returns to step 5.

21 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Diagrama de Casos de Uso (Calendário Partilhado)

22 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Casos de Uso Essenciais (Calendário Partilhado) Essential Use Case: arrangeMeeting USER INTENTION SYSTEM RESPONSIBILITY arrange a meeting request meeting attendees & constraints identify meeting attendees & constraints search calendars for suitable dates suggest potential dates choose preferred date book meeting

23 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Casos de Uso Essenciais e Fluxos de Tarefas Essenciais

24 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © Exemplo de HTA (gráfico) Borrow a book from the library go to the library find required book retrieve book from shelf take book to counter access catalog access search screen enter search criteria identify required book note location plan 0: do If book isnt on the shelf expected, do plan 2: do If book not identified from information available, do

27 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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 IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 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)


Carregar ppt "IPC (2003/04) :: Identificar Necessidades e Definir Requisitos João Falcão e Cunha, Miguel B. Gonçalves © 2003 1 6. Identificar Necessidades e Definir."

Apresentações semelhantes


Anúncios Google