Identificando necessidades e estabelecendo requisitos

Slides:



Advertisements
Apresentações semelhantes
Engenharia de Software
Advertisements

Análise e Projeto Orientado a Objetos
Metodologia de testes Nome: Gustavo G. Quintão
Requisitos de Software
APSOO Aula 03.
Prof.ª Adriana dos Santos Caparróz Carvalho
Identificando requisitos
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
NORMA NBR ISO OBJETIVO Esta norma - NBR fornece princípios e orientações para a empresa implementar um processo eficaz e eficiente de tratamento.
Engenharia de Software
Rational Unified Process(RUP)
Centrado na arquitetura
Faculdade de Ciências Sociais de Aplicadas de Petrolina – FACAPE
Análise de Processos de Negócios para um Sistema Integrado
SISTEMA DE INFORMAÇÕES DESENVOLVIMENTO DE SISTEMAS
O processo de coletar os requisitos (escopo do cliente)
Extração de Requisitos
Lafayette B. Melo – CEFET-PB - COINFO Interface do usuário, linhas de comando e menus Interface do usuário Linhas de comando Menus.
O processo do design da interação
Identificando necessidades e definindo os requisitos
Sistema de Controle de Motel
Engenharia de Requisitos Requisito – sistema Caso de uso - usuário
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Projeto Final - APGS Adriana P. de Medeiros
Especificação de Requisitos de Software com Casos de Uso
Seminário de Engenharia de Usabilidade
Expansão dos Casos de Uso
Lafayette B. Melo – CEFET-PB - COINFO Quando só o que se tem é um martelo, se acha que tudo que tem no mundo é prego (?) Como você vê o mundo em sua volta.
Prof.Alfredo Parteli Gomes
DIAGRAMA DE CASO DE USO Prof. Fabíola Gonçalves C. Ribeiro.
Informações e dicas importantes para implantação do SGA – Sistema de Gestão Ambiental em uma empresa Prof. Ronaldo.
Expansão dos Casos de Uso
Qualidade de Produto de Software
Metolodogia de Desenvolvimento de Data Warehouse
Caso de Uso - Definição Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema.
MODELO ESSENCIAL Modelo Ambiental
Introdução e Fundamentos Engenharia de Requisitos
CURSO TÉCNICO EM SEGURANÇA DO TRABALHO
Análise e Projeto de Sistemas UNIVERSIDADE DE CRUZ ALTA Ciência da Computação 2010/1.
Engenharia de Software
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Introdução A pesquisa é um procedimento reflexivo e crítico de busca de respostas para problemas ainda não solucionados.
Gestão de defeitos.
GERENCIAMENTO DE PROJETOS DE T.I
Laboratório de Programação
Processos do Design 27/09.
Trabalho de Engenharia de Software II
Requisitos de Software
Técnicas de avaliação de Interfaces Alunos: Joel Levandowski Ranieri R. Tremea Prof ª.:Cristina P. dos Santos URI - Universidade Regional Integrada do.
Técnicas e Projeto de Sistemas
Modelando Sistemas em UML
Como elaborar seu currículo? 04/2006 Um currículo bem feito não garante sua contratação mas um currículo mal elaborado elimina-o do processo seletivo.
Integração de Ferramentas CASE
Estruturas Organizacionais
Tarciane Andrade Análise de Casos de Uso Tarciane Andrade
Capítulo 3: Analisando Processos de Decisão de Negócios
Expansão dos Casos de Uso
Capítulo 6: SAD – Arquitetura e aspectos de rede e segurança
Processo e Qualidade.
Diagrama Casos de Uso.
Engenharia de Software
Erton W. Vieira Metodologias Ágeis, Qualidade de Software e Design Centrado no usuário: Pontos de Interação Erton W. Vieira.
Aula 02 de Eng. de Requisitos
O Modelo GOMS Fornece um modelo de Engenharia para a performance humana, capaz de produzir predições a priori ou em um estágio anterior ao desenvolvimento.
Engenharia de Software
Interações entre objetos
Analisar Caso de Uso. Copyright © 2002 Qualiti. Todos os direitos reservados. Qualiti Software Processes Analisar caso de uso | 2 Objetivos deste módulo.
Levantamento de Requisitos – Simulação do Supermercado
Extração de REQUISITOS Parte II. Segundo Pressman (1995), na analise e especificação de requisitos, a ambigüidade não só é possível mas é provável. “-
CMMI Capability Maturity Model Integration
Transcrição da apresentação:

Identificando necessidades e estabelecendo requisitos

Resumo A importância de requisitos Diferentes tipos de requisitos Coleta de dados para requisitos Descrição de tarefas: Cenários Casos de uso Casos de uso essenciais Análise de tarefas: AHT

O quê, Como e por quê? O quê: Dois objetivos: 1. Entender o máximo possível os usuários, seu trabalho e o contexto 2. Produzir um conjunto de requisitos estáveis Como: Atividades de coleta de dados Atividades de análise de dados Expressão como ‘requisitos’ Tudo isto é interativo

O quê, Como e por quê? Por quê: Definição de requisitoa: o estágio onde as falhas ocorrem mais frequente- mente Estabelecer requisitos claros é crucial

Estabelecendo requisitos O que os usuários querem? O que os usuários ‘necessitam’? Requisitos necessitam ser claros, refinados, completos e detalhados Entrada: documento de requisitos (talvez)‏ Saída: Requisitos estáveis Por quê ‘estabelecer’ ? Requisitos surgem da compreensão das necessidades Requisitos podem ser justificados e ralacionados com dados coletados

Diferentes tipos de requerimentos Funcional: O que o sistema deve fazer Historicamente o foco principal de atividades (Não-funcional: tam. de memória, resolução...) Dado: Que tipos ded dados necessitam ser armazenados? Como eles serão armazenados (database)?

Diferentes tipos de requerimentos Ambiente ou Contexto de uso: aspecto físicol: poeira? ruído? vibração? luz? calor? umidade? …. (ex. Caixa Eletrônico ruído)‏ aspecto social: compartilhamento de dados (síncrono/assíncrono)? Comunicação à longa distância? Trabalho individualmente? Privacidade? aspecto organizacional: Quão bom será o suporte organizacional? Quão facilmente poderá ser obtido? Há recurso para treinamento? A infra- estrutura de comunicação é estável ou eficiente? O gerenciamento é hierárquico?

Um exemplo extremo

Diferentes tipos de requerimentos Usuário: Quem são eles? Características: habilidade e conhecimento Uso do sistema: novato, especialista, casual, frequente Novato: instruções passo-a-passo, interação mais restrita, informações claras Especialista: flexibilidade, acesso/autonomia Frequente: atalhos Casual/não-frequente: instruções claras, comandos fáceis de entender (ex.: Menus)‏

Diferentes tipos de requerimentos Usabilidade: Captam as metas e as medidas de usabilidade associadas a um produto Metas de usabilidade: eficácia, eficiência, segurança, utilidade, capacidade de aprendizagem e memorização Os requisitos de usabilidade são relacionados a outros tipos de requisito que devemos estabelecer, como os tipos de usuários que irão interagir com o produto

Exercício: Tipos de requisitos Sugira um requisito de cada tipo (funcional, de dados, ambiental, de usuário e de usabilidade) para cada um dos seguintes cenários: Um sistema para uso em um restaurante self- service da universidade que permita aos usuários pagar a sua refeição utilizando um sistema de crédito

Exercício: Tipos de requisitos Sugira um requisito de cada tipo (funcional, de dados, ambiental, de usuário e de usabilidade) para cada um dos seguintes cenários: Um sistema que controla o funcionamento de uma usina nuclear Um sistema para dar suporte a equipes de design distribuídas (p.ex.: para design de um carro)‏

Coleta de dados para requisitos Propósito: Reunir informações suficientes, relavantes e apropriadas, de forma que um conjunto de requisitos estável possa ser produzido Mesmo no caso de existir um conjunto de requisitos iniciais, será exigido que a coleta de dados expanda, esclareça e confirme esses requisitos iniciais. Ela precisa englobar um vasto espectro de questões, visto que os tipos de requisitos que precisamos estabelecer são bastante variados Técnicas: Variadas, mas podem ser combinadas

Coleta de dados para requisitos Entrevistas: O entrevistador pode guiar o entrevistado se necessário Bom para explorar questões Requer tempo. Ambientes artificiais podem intimidar o entrevistado. Grupos de Foco: Grupo de entrevistas Bom para para coletar vários pontos de vista Ressalta áreas de consenso e conflito Possibilidade de dominarem certos tipos de personalidade

Coleta de dados para requisitos Questionários: Pode ser usado em conjunto com outras técnicas Bom para responder questões específicas Podem atingir várias pessoas com poucos recursos O design é crucial. O índice de resposta pode ser baixo. As respostas podem não ser o que você deseja Pesquisa por produtos similares: Bom para encontrar requisitos diretamente

Coleta de dados para requisitos Estudo de documentação: Procedimentos e regras são frequentemente escritos em manuais Bom para aprender sobre padrões, regras e procedimentos Não compromete o tempo dos usuários Não deve ser usado isoladamente O trabalho diário pode ser diferente dos procedimentos documentados

Contextualização Uma abordagem ao estudo etnográfico onde o usuário é especialista, designer aprendiz Uma forma de entrevista, mas no local de trabalho do usuário 2 a 3 horas Quatro grandes princípios: Contexto: observar a execução do trabalho e ver o que acontece Parceria: usuário e desenvolvedor colaboram Interpretação: observações interpretadas por usuários e desenvolvedores juntos Foco: focar no projeto para entender o que procurar

Problemas com coletas de dados (1)‏ Identificando e envolvendo as partes interessadas: usuários, gerentes, desenvolvedores, clientes?, empresários?, acionistas? Comprometer as partes interessadas: workshops, entrevistas, estudos de caso, colaboração com o time de desenvolvedores Usuários ‘reais’, não gerentes: tradicionalmente um problema de engenharia de software, mas hoje já é melhor

Problemas com coletas de dados (2)‏ Requisitos de gestão: versão controle, propriedade Comunicação entre as partes: com a equipe de desenvolvedores com cliente/usuário entre usuários… diferentes partes da organização usam diferentes terminologias Domínio do conhecimento distribuído e implícito: difícil de compreender articulação do conhecimento: como caminhar? Disponibilidade de pessoas chave

Problemas com coletas de dados (3)‏ Problemas políticos no seio da organização Dominância de determinadas partes interessadas Mudanças econômicas e de ambiente empresarial Equilibrar exigências funcionais e de usabilidade

Algumas diretrizes básicas Foco na identificação das necessidades das partes interessadas Envolver todas as partes interessadas Envolver mais de um representante de cada grupo interessado Usar uma combinação de técnicas de coletas de dados

Algumas diretrizes básicas Apoiar o processo com protótipos e descrição de tarefas Executar uma sessão piloto Você precisa de compromisso sobre os dados coletados e da análise a ser feita, mas antes de estabelecer isto de forma sensata, você precisa saber o que realmente quer Considere atentamente como registrar os dados

Interpretação e Análise de dados Comece a reunir os dados logo após a sessão Interpretação inicial antes de uma análise mais profunda Diferentes abordagens enfatizam elementos diferentes, por exemplo: diagramas de classe de sistemas orientados a objetos, diagramas de entidade-relacionamento para banco de dados

Descrição de tarefas Cenários uma história narrativa informal, simples, ‘natural’, pessoal, não genérica Casos de uso assumir interação com o sistema assumir detalhada compreenção da interação Casos de uso essenciais resumo dos detalhes não tem as mesmas hipóteses dos casos de uso

Cenário mostrando como as duas tecnologias, um telefone inteligente (smartphone) e o comércio sem fio (w-commerce) podem ser utilizados. Uma executiva está viajando de São Francisco para Paris em uma viagem de negócios. No caminho, ela pouco escapa de um congestionamento; consegue evitar tráfego porque seu telefone inteligente (smartphone) toca e envia uma mensagem de texto avisando que houve um acidente de trânsito em determinado ponto na rota normal de seu escritório até o aeroporto. Já no aeroporto, o telefone inteligente sensível à localização, notifica a companhia aérea que a executiva está chegando em breve, e um empregado da companhia imediatamente vai ao encontro dela para carregar sua bagagem. O display mostra que seu vôo está no horário e exibe a localização do portão em um mapa. No caminho em direção ao portão, ela faz o download de informações turísticas, tais como mapas e eventos que estarão acontecendo em Paris durante sua estada. Após localizar o seu assento no avião, ela começa a revisar todas as informações que descarregou. Vê que há uma ópera em cartaz a que está interessada em assistir e faz a reserva de um ingresso. O telefone inteligente pode realizar essa reserva utilizando o número do cartão de crédito, que tem gravado em sua memória. Isso significa que a executiva não necessita digitar o número do cartão toda vez que utiliza as comodidades do wCommerce. O sistema é seguro contra fraudes.

Caso de uso para organizar uma reunião 1. O usuário escolhe a opção de organizar uma reunião. 2. O sistema solicita ao usuário os nomes dos participantes. 3. O usuário digita uma lista de nomes 4. O sistema verifica se a lista é válida 5. O sistema solicita as restrições do usuário 6. O usuário digita suas restrições 7. O sistema busca nas agendas uma data que satisfaça às restrições 8. O sistema exibe uma lista de datas possíveis 9. O usuário escolhe uma das datas 10. O sistema marca a reunião na agenda 11. O sistema envia um e-mail para todos os participantes da reunião informando-os do compromisso

Caso de uso para organizar uma reunião Casos alternativos: 5. Se a lista da pessoa é inválida, 5.1 O sistema envia uma mensagem de erro 5.2 O sistema retorna ao passo número 2 8. Se não forem encontradas datas possíveis, 8.1 O sistema exibe uma mensagem adequada 8.2 O sistema retorna ao passo número 5