21/09/2012. Elicitação de Requisitos. Projeto de Interface Homem- Máquina. Prof. Esp. MBA Heuber G. F. Lima. Técnicas etipos de Requisitos

Documentos relacionados
Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Engenharia de Software.

Análise e Projeto Orientado a Objetos

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Curso de Sistemas de Informação. Karla Donato Fook DESU / DAI

Requisitos de Sistemas

2

Levantamento, Análise e Gestão Requisitos. Aula 10

Análise e projeto de sistemas

Análise de sistemas. Engenharia de Requisitos

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

Eng. de Requisitos: Atividades. Engenharia de Requisitos. Eng. de Requisitos: Processo. O Documento de Requisitos. Stakeholders. Estudo de Viabilidade

MODELAGEM DE SISTEMA Apresentação

Engenharia de Software ENGENHARIA DE REQUISITOS

Eng. de Requisitos: Atividades. Engenharia de Requisitos. Eng. de Requisitos: Processo. O Documento de Requisitos. Stakeholders

Análise e Projeto Orientado a Objetos

Engenheiros de software (algumas vezes conhecidos no mundo da TI como engenheiros de sistemas ou analistas ) e outros interessados no projeto

Análise de Requisitos

Engenharia de Requisitos

4/14/11. Processos de Engenharia de Requisitos. Engenharia de requisitos. Elicitação e análise. A espiral de requisitos

06/02/2014. Engenharia de requisitos. Requisitos de Software. Capítulo 6. O que é um requisito? Objetivos. Abstração de requisitos (Davis)

Requisitos de Software

Engenharia de Requisitos

Análise e Projeto de Sistemas I

Análise de Requisitos

Engenharia de Software. Arthur Mariano L NETO Aula 05

Documento de Requisitos*

Requisitos de Software

Uma compreensão completa dos Requisitos do Software é fundamental para obter um software e um processo de desenvolvimento com alta qualidade

Componentes de SIs. Pessoas Organiz. Tecnologia

Análise de Sistemas Aula 4

Técnicas de Elicitação de Requisitos

Instituto Federal de São Paulo Campus Presidente Epitácio. Disciplina: História da Ciência e da Tecnologia

Engenharia de Requisitos

3. Engenharia dos requisitos de software

Aula 7 - Análise de Requisitos: descrição de casos de uso. Análise de Sistemas Prof. Filipe Arantes Fernandes

001 - Atividade de Engenharia de requisitos

Agenda TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS ANÁLISE E PROJETO DE SISTEMAS. Aula 3 21/08/2012

LIVRO ENGENHARIA DE SOFTWARE FUNDAMENTOS, MÉTODOS E PADRÕES

Marcelo Henrique dos Santos

SOFTWARE REQUIREMENTS

Levantamento, Análise e Gestão Requisitos. Aula 05

DOCUMENTO DE VISÃO 1. TÍTULO DO PROJETO. 2. RESPONSÁVEL PELO DOCUMENTO Ciclano

- Prototipação Iterativa - Observação Direta

Processos de Engenharia de Requisitos

Análise e Projeto de Sistema. Daniel José Ventorim Nunes (IFES Campus Cahoeiro)

Engenharia de Requisitos

15/03/2018. Professor Ariel da Silva Dias Modelos de Processo de Software

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

Análise de Sistemas AULA 05 BCC Noturno - EMA908915A

APLICAÇÃO DA ENGENHARIA DE REQUISITOS E ESPECIFICAÇÃO DE REQUISITOS NA IDENTIFICAÇÃO DE ESCOPO DE SISTEMA

Análise e Projeto de Sistemas de Informação (APSI)

De Olho na Pista. Documento de Arquitetura. De Olho na Pista Documento de Arquitetura Data: 23/03/2013. AJA Software

Análise de Sistemas 3º Bimestre (material 1)

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

Requisitos de Software

Análise de Requisitos. Tema 4. Análise de Requisitos Profa. Susana M. Iglesias

Prof. Esp. Fabiano Taguchi

Aula 4 Engenharia de Requisitos

Capítulo 4. Engenharia de requisitos. Engenharia de Software Prof. Flávio de Oliveira Silva, Ph.D.

Classificação de Requisitos

Prof. Luiz A. Nascimento

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

Análise e Projeto de Sistemas

Processo de Desenvolvimento. Edjandir Corrêa Costa

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE

SCM Sistema de Controle de Motel I - DOCUMENTO DE REQUISITOS Versão 1

Princípios da Engenharia de Software aula 03

Engenharia Software I Aula 02

Projeto Integrador. <Projeto Integrador> Documento Visão. Versão <1.0>

Engenharia de Software

Requisitos de Software

Fatec. Curso Análise e Desenvolvimento de Sistemas. Requisitos de Software. Disciplina Teste de Software 3 Engenharia de Requisitos

Requisitos. Silvério Sirotheau

Engenharia de Software

Sistema Mobi-Lar Engenharia de Software

Capítulo 4. Engenharia de requisitos Pearson Prentice Hall. Todos os direitos reservados. slide 1

Engenharia de Software

Aula 1 - Introdução à disciplina e Processos de desenvolvimento de software e suas atividades básicas

Aula 2 - Modelos de Processo - cascata, iterativo e incremental e ágil

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Engenharia de Software Sistemas Sociotécnicos

Processo de Engenharia de Requisitos

Sistemas e software Proposta de especificação de software O fluxo de Requisitos Padrão para Especificação

Capítulo 4 Engenharia de Requisitos 1

ISO/IEC Processo de ciclo de vida

ENGENHARIA DE SOFTWARE

Definições e ciclo de vida

Introdução ao método de projeto OO. Prof. Cesar Augusto Tacla

Declaração de Escopo

Introdução ao método de projeto OO

Padrão para Especificação de Requisitos de Produto de Multimídia

1. OBJETIVO PROJETO 2. INFORMAÇÕES GERAIS DO PROJETO. SYSLOG Sistema de Logística DECLARAÇÃO DO ESCOPO. 1.1 Objetivo geral:

INTRODUÇÃO A ENGENHARIA DE SOFTWARE

Transcrição:

Elicitação de Requisitos Projeto de Interface Homem- Máquina Prof. Esp. MBA Heuber G. F. Lima Técnicas etipos de Requisitos 1

Processo de levantamento de requisitos Dificuldades 1) Cliente/usuário não sabem o que querem, ou não sabem expressar o que querem. 2) Expressam de requisitos em seus próprios termos. 2

Dificuldades 3) Sobre um mesmo problema: Requisitos diferentes para diferentes usuários. 4) Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema. Técnicas Levantamento Orientado a Ponto de Vista; Análise de Tarefa; Cenários; Etnografia; Prototipação. 3

Levantamento Orientado a Ponto de Vista Levantamento Orientado a Ponto de Vista Por que há diferentes tipos de usuário final Por que usuários tem interesses diferentes em requisitos - Sommerville p. 106 Perspectiva de cada pessoa sobre o sistema - (Pressman p. 242) 4

Levant.Orientado a Ponto de Vista Usuários num Sistema de uma clinica médica Faturista Médico Gerente Técnico Paciente Convênio Recepcionista Caixa Levantamento Orientado a Ponto de Vista Para levantar os pontos de vista, realiza-se : Entrevistas com os usuários Reuniões Obtém-se Serviços do sistema Entrada de dados Requisitos não funcionais Eventos de controle Exceções 5

Levantamento Orientado a Ponto de Vista Clínica Médica - Identificar Pontos de vista e Serviços Paciente Realizar Consulta/Exame Receber Laudo Ser atendido com seu convênio Realizar pagamento (caso atendimento particular) Levantamento Orientado a Ponto de Vista Clínica Médica - Identificar Pontos de vista e Serviços Recepcionista Cadastrar Paciente (Dados cadastrais) Verificar se paciente cadastrado Agendar Atendimento Checar guia de atendimento (caso de convênios) Preencher atendimento (Paciente, convênio, serviço, médico) Confirmar Atendimento Emitir recibos/formulário de entrega de resultado 6

Análise da Tarefa Análise da Tarefa A Análise da Tarefa é muito essencial para o design do sistema. Procura identificar os objetivos do usuário, suas tarefas, que estratégia utiliza para alcançar esses objetivos, como o usuário lida com emergências, que ferramentas utiliza, que problemas ele encontra. 7

Análise da tarefa Agentes pessoas que se relacionam com a tarefa. Por exemplo: indivíduos, grupo de indivíduos e componentes de software. Objetivo - o que o agente intenciona fazer ou alcançar. Ambiente situação do meio no qual estará descrito, como esse se encontrava antes e como se encontra depois da execução da tarefa por parte do agente. Análise da Tarefa Exemplo: Agente: Recepcionista Objetivo: Atender um Paciente, registrando um exame Ambiente: Após a ação Cadastrar Atendimento o Paciente está autorizado e é liberado para aguardar o atendimento. Recebe um Formulário de Devolução de Exame. 8

Cenários Cenários Cenários são textos ou narrativas sobre pessoas e suas atividades, criados com o intuito de apresentar o conceito de novos produtos. Essa construção textual permite inseri-los dentro de uma situação plausível mesmo que hipotética, identificar potenciais problemas, antecipar necessidades e até propor soluções alternativas para os problemas levantados. 9

Cenário Ambiente: descreve um estado inicial do ambiente onde o episódio acontece, caracteriza se o ambiente fisicamente, como as pessoas estão nele presentes. Atores ou agentes: aqueles que participam do episódio descrito interagem com o ambiente influenciando ou sendo influenciado. O roteiro: seqüência de ações e eventos representando o que os atores fazem durante o episódio, o que lhes acontece e que mudanças ocorrem no ambiente. Cenários Clínica Médica Cenários para atendimento de Paciente Ambiente Recepção de uma clínica, há um computador com um sistema de atendimento instalado. Atores Paciente Recepcionista 10

Cenários Roteiro 1. Paciente solicita atendimento entregando cartão de convênio e uma guia 2. Recepcionista: 1. Recebe Cartão de convênio e guia 2. Checa se convênio e serviços são credenciados 3. Checa se paciente já cadastrado 4. Cadastra paciente 5. Cadastra Atendimento e Confirmar 6. Emitir Formulário de Recebimento de laudo 7. Entrega formulário para o Paciente Clínica Médica Cenário Negativo 1. Paciente solicita atendimento entregando cartão de convênio e uma guia 2. Recepcionista: 1. Recebe Cartão de convênio e guia 2. [Convênio e serviços são credenciados, mas não há médicos para atendimento de tal serviço.] [Paciente não cadastrado e esqueceu CPF.] [A emissão de Formulário de Recebimento de laudo não acontece devido a problema na impressora] [Criança trazida pelo paciente desconecta cabo do computador] 11

Etnografia Etnografia Etnografia é uma técnica de observação Objetiva compreender requisitos sociais/organizacionais Analista se insere no ambiente no qual o sistema será utilizado e observa o trabalho diário e anota Ajuda a descobrir requisitos implícitos 12

Etnografia Requisitos descobertos com eficácia com a etnografia Técnica de etnografia: Identificar as áreas do usuário a serem observadas Obter aprovação da gerência Obter os nomes e funções das pessoas chave que estão envolvidas no estudo de observação Explicar a finalidade do estudo Etnografia - Desvantagens Consumir bastante tempo Analista ser induzido as erros em suas observações 13

Prototipação Prototipação Protótipo tem por objetivo explorar aspectos críticos dos requisitos de um produto O protótipo é indicado para estudar as alternativas de interface do usuário Problemas de comunicação com outros produtos A viabilidade de atendimento dos requisitos de desempenho. 14

Prototipação - benefícios Reduções dos riscos na construção do sistema; O uso de protótipo auxilia na elicitação e validação dos requisitos de sistema; A prototipação pode ser utilizada para elicitar requisitos quando há um alto grau de incerteza ou quando é necessário um rápido feedback dos usuários. 15

Tipos de Requisitos Requisitos do Usuário Declarações, em linguagem natural e também diagramas/formulários sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar. Descreve requisitos... de modo compreensível pelo usuários do sistema que não tem conhecimento técnico detalhados. Especificam comportamentos externos do sistema Tipos de Requisitos Requisitos de Sistema Descrições detalhadas dos requisitos do usuário Podem servir de base para o contrato, contendo especificações concretas e consistentes Base para o projeto de sistemas Define o que o sistema deve fazer e não como deve ser implementado Sommerville p. 91-95 16

Tipos de Requisitos Requisitos de Sistema Classificação Sommerville p. 26-27, Peters p. 102 Resumindo Requisitos Funcionais Requisitos Não Funcionais 17

Requisitos Funcionais São declarações de funções que o sistema deve fornecer, De como o sistema deve reagir a entradas específicas Como deve se comportar em determinadas situações. Em alguns casos: O que o sistema não deve fazer. A especificação deve ser completa e consistente, não devem ter informações contraditórias. Negligência nessa fase = problemas na construção. Requisitos Não Funcionais Os requisitos não funcionais são aqueles que não dizem respeito diretamente às funções Eles podem estar relacionados a propriedades de sistemas. Eles podem definir restrições para o sistema capacidade dos dispositivos de E/S, representações de dados utilizadas nas interfaces de sistema. O não cumprimento de um requisito não funcional pode tornar o sistema inútil. Os requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido. Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado 18

Atributos de requisitos não-funcionais (Deutsch and Willis, 1988; Sommerville, 1996) eles devem ser objetivos um requisito não-funcional é objetivo se não expressa um desejo, uma meta, ou uma opinião pessoal. eles devem ser testáveis um requisito não-funcional é testável se há algum processo pelo qual o requisito possa ser testado Segundo SWEBok... 19

Processos de Design da Interação Requisitos do Produto: São os requisitos que especificam o comportamento do produto. Eles podem estar relacionados a propriedades de sistemas, tais como: Facilidade de Uso (Usabilidade): requisitos que se relacionam ou afetam a usabilidade do sistema. Ex. Sistema Deverá ter uma interface web adaptada para portadores de necessidades especiais ; Confiabilidade: estabelecem a taxa aceitável de falhas. Ex.: Caso ocorra erro no processamento X o sistema deverá retornar à situação onde fora iniciado o processamento ; Eficiência: Desempenho: define o tempo de resposta esperado, a rapidez que o sistema deve operar e a quantidade de memória que ele requer; Ex.: A operação noturna não poderá exceder ao período de 2 horas ; Espaço: define os requisitos de capacidade de armazenamento de dados que o sistema necessita. Processos de Design da Interação Requisitos do Produto: Portabilidade: restrições sobre as plataformas de hardware e de software nas quais o sistema será implantado e/ou sobre o grau de facilidade para transportar o sistema para outras plataformas. Ex.: A aplicação poderá ser instalada em dispositivos com o S.O. Android Ice Cream Sandwich 20

Processos de Design da Interação Os requisitos organizacionais são procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor, tais como: Entrega: especificam quando o produto e seus documentos devem ser entregues; Ex.: A cada entrega de produto à homologação deverá ser feito e assinado um termo de aceite ; Implementação: envolve a linguagem de programação ou o método de projeto utilizado; Padrões: especifica os padrões da organização e como os requisitos devem atendê-los. Processos de Design da Interação Os requisitos externos abrangem todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles, destacam-se: Interoperabilidade: definem como o sistema interage com outras organizações; Éticos: são definidos em um sistema para garantir que este será aceitável para seus usuários e o publico em geral; Legais: devem ser seguidos para assegurar que o sistema opera de acordo com a lei. Privacidade: quem pode ter acesso à informação; Segurança: como proteger a informação de acesso não autorizado. 21

22