Baixe o app para aproveitar ainda mais
Prévia do material em texto
Roteiro da Aula 2 � Introdução � Processos � Tipos � Problemas � Recomendações � Especificação Introdução 3 � O que são Requisitos? � Moderno Dicionário da Língua Portuguesa � “1.Condição a que se deve satisfazer para que uma coisa fique legal e regular” � Os requisitos de um sistema software � Definir o que o sistema deve fazer � Suas restrições sobre suas operações e implementação � Exemplo: � “Eu quero que meu sistema permita realizar buscas por cor dos olhos” Introdução 4 Definição dos requsitos Projeto de sistema de software Implementação de teste de unidade Integração e teste de sistema Operação de manutenção Modelo Em Cascata Introdução 5 � “O começo é a parte mais importante do trabalho.” (Platão) � Muitos problemas de Engenharia de Software originam na fase de requisitos � Atraso na entrega do sistema � Aumento dos custos � Erros de arquitetura Introdução 6 � Portanto… � Uma COMPREENSÃO completa dos requisitos de software é fundamental para que o desenvolvimento de software seja bem sucedido � A satisfação dos requisitos especificados pelos usuários é a pré-condição básica para o sucesso de um software � Software mal especificado � Desapontar o usuário; � Causar problemas à equipe de desenvolvimento; � Constantes modificações Introdução 7 � Engenharia de Requisitos � Objetivo � SISTEMATIZAR o processo de definição dos requisitos, obtendo uma ESPECIFICAÇÃO CORRETA e COMPLETA dos requisitos (IEEE, 1991) � Desenvolver uma especificação COMPLETA, CONSISTENTE e NÃO AMBÍGUA, servindo de base para um acordo entre TODAS as partes envolvidas e descrevendo O QUÊ o produto de software irá fazer, mas não COMO ele será feito (Boehm, 1989) 8 Fonte: SWEBOK v3 9 � Os Requisitos de Software estão intimamente relacionados com as outras áreas de conhecimento da ES � design, testes, manutenção, configuração, gestão, processos, modelos e métodos. � TODO Processo possui ESSA ETAPA de Requisitos � O Que muda São como Técnicas, uma Interação e como ESPECIFICAÇÕES geradas. � RUP � SCRUM � XP Processo de Requisitos 10 Elicitação • Formulários • Entrevistas Análise • Protótipos • Caso de Uso Especificação de requisitos • Documentos Validação de Requisitos • Documento de Validação Obetivo do processo: Criar e Manter um Documento de Requisitos • Documento de Requisitos so de Requisitos Elicitação • sFormulários • EntrevistasE i Análise • Protótipos • CasoC ded Uso Especificação de requisitos • osDocumento Validação de Requisitos • Documento ded Validação Obetivo do Requisito • Documento de Requisitos so d Ob tos so d Ob too proccesssoo: CCCCCCriiiaar e MMMMMMMaanntteer umm DDDooccummeentttoo de R Requisitos 11 � Não é uma atividade apenas de front-end discreta do ciclo de vida do software � É SIM um processo iniciado no início de um projeto que continua a ser refinado ao longo do ciclo de vida Requisitos 12 � Requisito � Condição necessária para obtenção de certo objetivo, ou preenchimento de certo objetivo. � Especificação � Descrição minuciosa das características que um material, uma obra, ou um serviço deverão apresentar. � Portanto, Especificação é diferente de Requisitos � Especificação de Requisitos � Serve para documentar a análise realizada Tipos de Requisitos 13 � Requisitos Funcionais � RF são requisitos diretamente ligados a funcionalidade do software Exemplo: � “O sistema deve conter um formulário para a entrada dos resultados dos testes clínicos de um paciente”. Tipos de Requisitos 14 � Requisitos Não Funcionais � Expressam restrições que o software deve atender ou qualidades específicas que o software deve ter Exemplo: � “Dependendo do resultado do teste, somente o Supervisor pode efetuar a entrada do resultado do teste de um paciente. (RNF de confidencialidade)” � O sistema deve emitir um recibo para o cliente, com o tempo máximo de 8 segundos após a transação. (RF “,” RNF de performace). Quantificação dos Requisitos 15 � Requisitos de Software devem ser declarados de forma clara e inequívoca � Em particular, isso é importante para os requisitos não- funcionais. � Se for o caso, a declaração deve ser de maneira quantitativa � Evitar que a interpretação seja feita de forma subjetiva, como por exemplo: � "o software deve ser confiável", “ � o software deve ser user-friendly ". � Dois exemplos de requisitos quantificados já foram dados � “Dependendo do resultado do teste, somente o Supervisor pode efetuar a entrada do resultado do teste de um paciente. (RNF de confidencialidade)” � O sistema deve emitir um recibo para o cliente, com o tempo máximo de 8 segundos após a transação. (RF “,” RNF de performace). Atores 16 � São os evolvidos do processo de requisitos de softwares � Usuários: grupo é composto por aqueles que vão operar o software � Clientes : Este grupo é composto por aqueles que encomendaram o software ou que representam mercado-alvo do software � Os analistas de mercado : um produto de mercado de massa não vai ter um cliente de comissionamento , de forma pessoal de marketing são muitas vezes necessários para estabelecer o que precisa o mercado e agir como clientes proxy. � Reguladores : muitos domínios de aplicação, tais como bancos e transportes públicos, são regulados. Software nestes domínios devem cumprir com os requisitos da regulamentação autoridades � Os engenheiros de software : Estes indivíduos têm um interesse legítimo em lucrar com o desenvolvimento de o software , por exemplo , reutilizando componentes ou de outros produtos . Problemas com Requisitos Elicitação Especificação 17 � Ignorar um grupo de clientes � Ignorar um único cliente � Omitir um grupo de requisitos � Permitir inconsistências entre grupos de requisitos � Aceitar requisito inadequado � Aceitar requisito incorreto, indefinido, ou impreciso � Aceitar um requisito ambíguo e inconsistente � Técnicas e Ferramentas Inadequadas � Comunicação Ineficiente � Documentos mal escritos � Palavras ambíguas � Mal divididos � Confusão de conceitos Recomendações 18 � Usar técnicas de comunicação � FAST(Facilitaded Application Specification Techniques) � Usar técnicas de Análise � Análise Estruturada � Análise Orientada a Objetos � Usar técnicas de elicitação: � Entrevista � Questionário � Role Playing � Workshop de Requisitos � Cenários � Brainstorming � Storyboards � Protótipação Recomendação número 1 – Entender Engenharia de Requisitos Recomendações 19 � Utilizar guias de recomendações de como elaborar uma especificação de requisitos � Praticar escrita, praticar leitura, Recomendação número 1 – Entender Engenharia de Requisitos Exemplos de Casos de Elicitações 20 � Com o objetivo de ilustrar os problemas enfrentados na coleta de requisitos, segue alguns casos práticos � Sistema de relatórios de logística � Sistema de denúncias � Sistema de venda de revistas on-line � Sistema de marketing � Sistema de TV Mais Recomendações 21 � Se você pretende ser um Engenheiro de Requisitos.. � Capacidade para compreender conceitos abstratos, reoorganizar esses conceitos em divisões lógicas e sintetizar soluções com base em cada divisão. � Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas.� Capacidade de se comunicar bem de forma escrita e verbal. � Capacidade de “ver a floresta ao invés das árvores”. � SABER ESCREVER! Processo de Requisitos 22 Elicitação • Formulários • Entrevistas Análise • Protótipos • Caso de Uso Especificação de requisitos • Documentos Validação de Requisitos • Documento de Validação Obetivo do processo: Criar e Manter um Documento de Requisitos • Documento de Requisitos Elicitação de requisitos � Para complementar o que é um requisito de software, a sua importância sua dificuldade assita ao vídeo: � http://www.youtube.com/watch?v=t0so6Nagjns Elicitação de Requisitos 24 � Está preocupado com as ORIGENS dos requisitos de software e COMO o � engenheiro de software pode recolhê-los. � É a primeira etapa na construção de uma compreensão do software � É fundamentalmente uma atividade HUMANA e é o lugar onde as partes interessadas são identificados e as relações estabelecidas entre a equipe de desenvolvimento o cliente. � Um dos princípios fundamentais de um bom processo de elicitação de requisitos é o da efetiva comunicação entre os vários intervenientes. Elicitação de Requisitos 25 � Não é uma atividade PASSIVA e que, mesmo se as partes interessadas cooperativos e articulados são disponível, o engenheiro de software tem que trabalhar duro para obter as informações CORRETAS. Elicitação de requisitos Problemas decorrentes da coleta de requisitos!! Elicitação de requisitos Problemas decorrentes da coleta de requisitos!! Elicitação de requisitos � Técnicas � Entrevistas � Dinâmica de Grupo � Oficinas � JAD � Técnicas de Criatividade em Grupo � Brainstorming � Técnica de grupo nominal � Votação das melhores idéias � Delphi � Mapas Mentais � Diagrama de Afinidades � Técnicas de Tomada de Decisão em Grupo � Questionário e Pesquisas � Observações � Protótipação Elicitação de requisitos � Entrevistas � Meio formal ou informal de se descobrir informações das partes interessadas através de conversas diretas com as mesmas. � Normalmente é feita através de perguntas PREPARADAS ou espontâneas e do REGISTRO de RESPOSTAS � São frequentemente conduzidas individualmente, mas podem envolver múltiplos entrevistadores e/ou entrevistados Elicitação de requisitos � Entrevistas: boas práticas: � Deve fazer parte o planejamento ANTES da entrevista � Quem será entrevistado? � Qunto tempo para cada um? � Quem irá realizar a entrevista? � Qual a diponibilidade do entrevistador? � Qual a disponibilidade do entrevistado? � Agende com antecedência Elicitação de requisitos � Entrevistas: boas práticas: � Planeje o que será perguntado � Faça um guia de perguntas � Entreviste as pessoas certas! Não perca tempo! � Registre! Fatalmente você irá esquecer! � Câmeras, gravadores, lápis, papel � Não deixe nada mal entendido � Formalize a entrevista depois de realizá-la � (envie um e-mail com seu entendimento) Elicitação de requisitos � Evite fazer entrevistas “on-line” � Perda de informações � Informações redundantes � Informações ambíguas � Entrega com atraso � Não entregar Mais informações em: http://www.slideshare.net/fernandosantucci/treinamento-jad-joint-application-design Elicitação de requisitos � Dinâmica de grupo � Unem as partes interessadas e especialistas no assunto para aprender a respeito das suas expectativas e atitudes sobre um software � Um moderador treinado guia a grupo através de uma discussão interativa, planejada para ser mais informal do que uma entrevista individual. � Geralmente quem idealiza essa dinâmica são profissionais de RH � Por ser mais difícil de elaborar é pouco utilizada em desenvolvimento de sistemas � Exemplo: Jogos! Elicitação de requisitos � Oficinas � São sessões focadas que unem as partes interessadas (multidisciplinar) para definir os requisitos do produto � Os problemas podem ser descobertos e resolvidos mais rapidamente do que em sessões individuais � Exemplos � Indústria de software: Join Application Design (JAD). � Técnicas para condução de reuniões � Indústria de manufatura: Desdobramento da Função de Qualidade (QFD) Elicitação de requisitos � Técnicas de criatividade em grupo � Brainstorming � Técnica de Grupo Nominal � Amplia o Brainstorming adicionando um processo de votação para armazenar as várias idéias � Ténica Delphi � Detalhado nos próximos slides � Mapas Mentais � Detalhado nos próximos slides � Diagrama de Afinidades � Detalhado nos próximos slides Fonte: http://www.entrepreneurship-education.com/business-ideas.html Brainstorming A figura retrata bem o que é uma tempestade de idéias! (“brainstorming”) Fonte: http://lateralaction.com/articles/brainstorming/ Brainstorming Resultado de um brainstorming! Elicitação de Requisitos � Detalhando melhor a Ténica Delphi � Consulta um grupo de especialistas a respeito do futuros software através de um questionário, que é repassado continuadas vezes até que seja obtida uma convergência das respostas, um consenso, que representa uma consolidação do julgamento intuitivo do grupo. � Pressupõe-se que um jultamento coletivo bem orgnizado é melhor do opnião de um só indivíduo � Características: � Anonimato dos respondentes � Representação estatística da distribuição dos resultados � Feedback de respostas do grupo para reavaliação das rodadas � Recomendado quando não se dispões de dados quantitativos, ou estes não podem ser projetados para o futuro com segurança Elicitação de requisitos � Usados em várias áreas � “Identificação de novas cocepções para sistema de exploração de petróleo até o ano 2000, em lâminas dé água superiores a 1000 m” � Fonte: O futuro energético:Uma previsão para o ano 2000 usando o método Delphi. James Wright. Delphi Outras referências: Delphi – Uma ferramenta para apoio ao planejamento Prospectivo. Fonte: http://www.iea.usp.br/tematicas/futuro/projeto/delphi.pdf Elicitação de requisitos Esse é um fluxograma Que ilustra cada etapa Da técnicas Delphi Elicitação de requisitos Delphi Nos próximos slides, você verá as telas de um software gratuíto (sem necessidade de Instalação) que pode ser usado para aplicar a ténica delphi. Acesso ao software: http://armstrong.wharton.upenn.edu/delphi2/ Elicitação de requisitos Delphi Elicitação de requisitos •Use no mínimo 5 especialistas e no máximo 20 •Os especialistas devem possuir algum conhecimento, mas não muito •Grupo pode ser Heterogêneo ou Homogêneo, depende do sistema. Cadastrando os especialistas! Elicitação de requisitos � Ténica Delphi � Leituras recomendadas: � Harold A. Linstone and Murray Turoff, Editors Linstone & Turoff (1975). The Delphi Method: Techniques and Applications : a heavily referenced work on this method with an extensive bibliography. � # Sackman, H. (1974), "Delphi Assessment: Expert Opinion, Forecasting and Group Process", R-1283-PR, April 1974. Brown, Thomas, "An Experiment in Probabilistic Forecasting", R-944-ARPA, 1972 - the first RAND paper. � # Bernice B. Brown (1968). "Delphi Process: A Methodology Used for the Elicitation of Opinions of Experts." : An earlier paper published by RAND (Document No: P-3925, 1968, 15 pages) Elicitação de requisitos � Detalhamento dos Mapas Mentais � Idéias criadas através de brainstormingindividuais são consolidadadas num único mapa mental que reflete a existência de atributos comuns e diferenças de entendimento, além de gerar novas idéias Mapas Mentais Exemplo Mapas Mentais Enquanto acontece O Brainstorm Vc pode realizar O mapa mental. É uma maneira de Organizar os pensamentos Exemplo de Mapas Mentais Exemplo de Mapas Mentais Exemplo de Mapas Mentais Ferramentas de Apoio � Mapas Mentais � Ferramenta e modelos para criação de mapas mentais: � XMind: � http://www.xmind.net/ � Modelos de Mapas Mentais � http://www.mapasmentais.com.br/modelos/eventos/eventos.asp Elicitação de requisitos � Diagrama de afinidades � Permite que um grande número de idéias seja organizado em grupos para revisão e análise � Utilizado para organizar idéias e dados � Utilizado DEPOIS de um branistorming � Utilizado quando existe dificuldade em se organizar tantas idéias Atenção!! Vamos usar essa técnica em nossa atividade prática!!! Elicitação de requisitos � Diagrama de afinidade: PROCESSOS � Registre cada idéia em um cartão � Agrupe idéias que parecem estar relacionadas � Ordene os cartões em grupos até que todos sejam utilizados Elicitação de requisitos Passo 2 – Registrar as idéias Passo 1 - Brainsmtorm Elicitação de requisitos Passo 3 – Agrupar as idéias = diagrama de afinidades Elicitação de requisitos � Sugestão de ferrmenta: http://www.discover6sigma.org/d6slab/affinity/ Elicitação de requisitos � Técnicas de tomada de decisão em grupo � Processo de avaliação de múltiplas alternativas onde uma resolução com ações futuras é esperada. Podem ser realizadas para gerar, classificar e priorizar os requisitos � Unanimidade � Todos concordam � Maioria � Mas de 50% concordam � Pluraridade � O maior bloco decide,mesmo que a maioria não seja alcançada � Ditadura � Apenas um decide Elicitação de requisitos � Questionários e Pesquisas � Recomendado para uma grande audiência � Quando uma análise estatística é necessária � Podem ser aplicados juntamente com entrevistas ou formulários � Não faça sem antes QUESTIONAR: � Qual a melhor maneira de realizar a pesquisa? � Como podemos ter a melhor taxa de resposta possível? � Devemos usar uma empresa de pesquisa? � Deve ser on-line ou presencial? Elicitação de requisitos � Questionário � Vantagens: � Atinge grande número de pessoas, mesmo que estejam dispersas geograficamente � Menores gastos com pessoal, não exige treinamento de quem vai aplicar, como por exemplo a Dinâmica de Grupo exige. � Garante anonimato das respostas � Permite que as pessoas respondam no momento que achar conveniente � Não expõe ninguém as influências das opniões pessoais do entrevistado Elicitação de requisitos � Questionário � Desvantagens: � Exclui algumas pessoas (deficientes visuais,analfabetos) � Impede o auxílio de informantes quando este não entende corretamente as instruções e perguntas � Impede o conhecimento das circunstâncias em que foi respondido (isso pode influenciar na resposta) � Não oferece garantia de que serão devolvidos � Precisam ser pequenos (os grandes não serão respondidos) Elicitação de requisitosdo Escopo � Questionários e Pesquisas: BOAS PRÁTICAS � Prepare seu levantamento ANTES � Faça um esboço no editor de texto � Pergunte apenas o que realmente é relevante � Evite um número muito grande de perguntas � Ninguém quer responder algo muito grande � Estruture a pesquisa em grupos similares e ordenados � Na primeira página, deixe claro os objetivos da pesquisa � Questões de identificação pessoal deixe no fim (contatos, etc) � Quebre em várias páginas � Assusta menos � Permite pular páginas Elicitação de requisitos � Questionários e Pesquisas: BOAS PRÁTICAS � Não confunda opções de múltpla escolha e escolha única � É comum confundir! � Use lógica condicional � Evita que pessoas não precise ler perguntas que não as interessa � 1- “Você vai a academia regularmente?” (Sim ou não?) � “2- Qual equipamento vc usa na academia?” � Antes da pergunta 2 é bom dizer que ela é necessária apenas se a resposta da 1 for sim. Elicitação de requisitos Questionários e Pesquisas: BOAS PRÁTICAS � Padronizar as opções de respostas � Muito satisfeito, satisfeito, não satisfeito ou � 1, 2, 3 para indicar satisfação. � Utilize imagens com moderação � Gasta tinta para impressão � Lento para carregar (on line) Elicitação de requisitos Questionários e Pesquisas: BOAS PRÁTICAS � Esteja ciente dos direitos autorais e leis de proteção de dados! � Não violar direitos autorais sobre a imagem � Não incluir qualquer coisa que seja difamatória � Se está coletando dados pessoais, esteja ciente das leis de proteção de dados � Solicitar todas as permissões necessárias para uso das informações Elicitação de requisitos � Questionários e Pesquisas: BOAS PRÁTICAS � Seja educado � O entrevistado está fazendo um favor � Incluir mensagem de saudação BREVE no início � Deixe claro a política de privacidade Mais informações em: http://www.demographix.com/resources/online_survey_best_practice.asp http://pareonline.net/pdf/v10n12.pdf Recomendacões práticas para a ER sugeridas pela IEEE-830 [Byrne 1994]. Elicitação de requisitos � Questionários e Pesquisas: Softwares � Vc pode criar no Google Docs � Vc pode criar no Tidia � Vc pode procurar ferramentas gratuítas para isso! � Procure SEMPRE no: http://sourceforge.net/ � Mas atenção!!! Questionários on-line costumam ter um número pequeno de adesão! Elicitação de requisitos � Observações � Fornece uma maneira direta de examinar indivíduos em seu ambiente e como desempenham o seu trabalho ou tarefas e executam processos. � É indicado para situações de resistência na coleta de requisitos � Realizada por um observador que visualiza um usuário executando seu trabalho; ou � Observador participante. Elicitação 75 � Cenários � Cenários é um valioso meio para fornecimento de contexto para a elicitação das necessidades dos utilizadores. � Eles permitem o engenheiro de software fornecer um quadro para perguntas sobre as tarefas do usuário ao permitir Perguntas "e se" e "Como isso é feito" Elicitação 76 � Cenários � Notação � Cenários geralmente são representados por narrativas textuais, em linguagem natural, que, freqüentemente, são aprimoradas por gráficos, diagramas e imagens [RYS 2000]. Podem também ser representados através de protótipos, storyboards, vídeos, maquetes, ou até mesmo por situações físicas planejadas para suportar as atividades de um usuário [CAR 2000]. Um exemplo de cenário pode ser observado abaixo: � Maria deseja utilizar o caixa eletrônico do banco X para retirar RS 50,00 em dinheiro de sua conta corrente; Ela passa seu cartão no leitor do caixa eletrônico pronto para ser usado. O sistema valida o cartão e, em seguida, requisita a senha a Maria. Pelo teclado, Maria digita sua senha. O sistema valida a senha digitada e mostra na tela o menu de opções de transações. Maria escolhe a opção saque, tocando no botão com esta denominação que está na tela; em seguida escolhe R$ 50,00 no menu de possíveis quantidades de dinheiro. O caixa automático verifica a quantia escolhida, a existência de fundos, aprova a transação e libera a quantia correta e um recibo do saque. Maria pegao dinheiro e o recibo nos locais especificados, o sistema debita a quantia da conta corrente, exibe uma mensagem, pedindo para o cliente certificar-se de que está de posse do seu cartão magnético; e, por fim, mostra novamente o menu de opções de transações. � Mostra o cenário para o usuário de pois faz perguntas a respeito. Elicitação de requisitos � Protótipos � Modelo funcional do produto esperado � Permitam que as partes interessadas façam experiências com um modelo do seu produto final ao invés de somente discutirem representções abstratas dos seus requisitos � Protótipos suportam o conceito de elaboração progressiva � Quando suficientes ciclos de coletas de feedback forem realizados, os requisitos obtidos do mesmo estarão completos para se partir para fase de concepção ou construção � TÉCNICA MUITO PODEROSA � PODE SER USADO TAMBÉM NA ANÁLISE DE REQUISITOS E NA VALIDAÇÃO
Compartilhar