Nivelamento - Engenharia de Requisitos

1.3 ENGENHARIA DE REQUISITOS\nMPS - Parte 1 - Introdução Engenharia de Requisitos\n• Tipos de Requisitos\n• Elicitação e Especificação de Requisitos\nMPS - Parte 1 - Introdução Requisitos:\n• Definições:\n – Para Pfleeger (2004), um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos\n – No SWEBOK (2004), um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real\n – Segundo Nuseibeh e Easterbrook (2000), requisitos são expressões das necessidades de um stakeholder para atingir objetivos particulares Requisitos\n• Um requisito é (IEEE Software Engineering Standards, 1987):\n - Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo.\n - Uma condição que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto... Visões para Requisitos\nMundo\n \n sistema\nDesenvolvido\nRequisitos do Usuário\n\n Projecto do Sistema\nArquitetura\n (Alexander, 2001)\n satisfaz\n soluções desenvolvidas\n utilizando sistemas\n novos e existentes\n\n... precisam ser apresentados de maneiras diferentes Visões para Requisitos\n• Requisito = Declaração para ser entendida pelos usuários ou pelos desenvolvedores?\n - Requisitos do usuário: declarações, em formato ou linguagem inteligível, sobre as funções que o sistema deve oferecer e as restrições sob as quais deve operar\n - Requisitos de sistema: estabelecem detalhadamente as funções e as restrições de sistema, em um formato mais apropriado para a implementação Requisitos de Software e de Sistema\n• Sistema - Combinação interativa de elementos (hardware, software, firmware, pessoas, informações, técnicas, facilidades, serviços...)\n Requisitos de Sistema - São os requisitos do sistema como um todo\n Requisitos de Software - São os requisitos dos componentes de software derivados dos requisitos do sistema Classificação de Requisitos\n• Requisitos Funcionais\n - Requisitos diretamente ligados a funcionalidade do software, descrevem as funções que o software deve executar\n - Um requisito funcional descreve uma interação entre o sistema e seu ambiente\n - Exemplo: \"O sistema deve prover um formulário um relatório com os resultados dos testes clínicos de um paciente\" Exemplos de Requisitos Funcionais\n• [RF001] Permitir a criação, edição e exclusão de documentos de forma colaborativa entre os técnicos.\n• [RF002] Permitir a inclusão de múltiplos documentos de um mesmo tipo para uma mesma operação\n• [RF003] Manter histórico de versões dos documentos, registrando os técnicos que fizeram as alterações Exercício 1 – Ferramenta para Planejamento e Controle de Projeto Final\n• Em grupo – identifiquem Requisitos Funcionais\npara:\n– Ferramenta para Planejamento e Controle de Projeto Final\n• A ferramenta deve ser uma aplicação Web que permita tanto ao aluno quanto ao orientador o planejamento e controle do projeto final Exercício 2\n• Forneça alguns exemplos de Requisitos Funcionais para:\n– ferramenta para gerência de Processo em ambientes de desenvolvimento de software;\n– aplicação Web para controle de tarefas – com divisão de status em: a serem feitas, em progresso, pendentes, com impedimento, em validação e feitas;\n– ferramenta para Planejamento e Controle de Casos de teste; Classificação de Requisitos\n• Requisitos Não-Funcionais\n– São requisitos que expressam condições que o software deve atender ou qualidades específicas que o software deve ter\n– Em vez de informar o que o sistema fará, os requisitos não-funcionais colocam restrições no sistema\n– Requisitos não-funcionais podem ser mais críticos que requisitos funcionais\n• O sistema não os satisfaz, muitas vezes o sistema se torna inútil Requisitos Não-Funcionais\n• Requisitos não-funcionais devem ser mensuráveis\n– Deve-se associar forma de medida/referência a cada requisito não-funcional elicitao Medidas de Requisitos Não-Funcionais\nPropriedade\tExemplos de Medidas\nVelocidade\tTransações Processadas/seg\nTamanho\tTempo de resposta ao usuário\nK bytes\tTempo de treinamento para execução de uma tarefa\nFacilidade de Uso\tTaxa de ocorrência de falhas\nConfiabilidade\tTempo médio entre falhas\nRobustez\tProbabilidade de corrupção de dados Requisitos NF devem ser verificáveis – Exemplos:\nRequisito Verificável\nO banco de dados ZZ deve possuir oito campos por registro.\nRequisito Não Verificável\n\"O banco de dados ZZ deve ser flexível\"\n\"MNOP deve ser seguro\"\n\"O sistema CE deve processar depósitos rapidamente\" Tipos de Requisitos Não Funcionais\n• Algumas Categorias de Requisitos Não Funcionais:\n— Requisitos de segurança\n— Ex: utilização de protocolo de comunicação criptografado (https,\n— Requisitos de Confiabilidade\n— Ex: sistema deve estar disponível para os usuários 7 dias por\n— Requisitos de Desempenho\n— Ex: o tempo de resposta máximo de uma operação no sistema\n— Requisitos de Usabilidade\n— Requisitos de Portabilidade Exercício\n• Forneça alguns exemplos de Requisitos Funcionais e Requisitos Não-Funcionais para:\n— Ferramenta para Planejamento e Controle de Projeto Final\n— Ferramenta para Planejamento de Processo em ambientes de apoio a projetos de desenvolvimento de software;\n— Aplicação Web para controle de tarefas – com divisão de status: em válidas, em progresso, pendentes, com finalização e feitas;\n— Ferramenta para Planejamento e Controle de Casos de Teste; ELICITAÇÃO DE REQUISITOS\nMPS - Parte 1 - Introdução Elicitação de Requisitos\n• Trata-se da identificação dos requisitos em si\n • Formação da ideia inicial do sistema\n • Compreensão do domínio do problema\n • \"Requisitos não contra eles\" (AMBLER)\n • \"Trabalho com os usuários\"\n • \"Tem que aceitar os requisitos como resultado de uma relação mal conduzida\" (OAD)\n• Também denominado de levantamento ou descoberta de requisitos\n• A elicitação de requisitos é proativa\n• Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas do domínio: serviços que devem ser fornecidos bem como restrições\n Elicitação de requisitos\n• Atividades do processo\n • Compreensão do domínio\n • Coleta de requisitos através da interação com os stakeholders\n • Classificação dos requisitos em grupos estruturados\n • Resolução de conflitos advindos das diferentes visões dos stakeholders\n • Definição de prioridades\n • Verificação de requisitos (completos e consistentes)\n Principais Problemas\n• Volatilidade\n • Tipos de Problema\n • Entendimento\n • Escopo\n Elicitação de Requisitos:\n - Problemas comuns na elicitação de requisitos:\n - Problemas de escopo:\n - O limite do sistema é mal definido, ou detalhes técnicos desnecessários confundem os objetivos globais\n - Problemas de entendimento:\n - Os clientes/usuários não estão completamente certos do que é necessário, não têm pleno entendimento do domínio do problema, têm dificuldade de comunicar as capacidades\n - Problemas de volatilidade:\n - Os requisitos mudam com o tempo Técnicas para elicitação de requisitos\n - Procedimentos genéricos:\n - Perguntar\n - Observar e inferir\n - Discutir e formular\n - Negociar a partir de um conjunto-padrão\n - Estudar e identificar problemas\n - Suportar Técnicas para elicitação de requisitos\n - Classificação das Técnicas para Elicitação de Requisitos\n (Nuseibeh and Easterbrook 2000)\n - Técnicas Tradicionais:\n - Entrevistas, questionários, análise de documentação existente, etc.\n - Técnicas de elicitação em grupo:\n - Brainstorming, workshops FAST/JAD etc.\n - Prototipação:\n - Scratch/storyboards, protótipos descartáveis\n - Técnicas orientadas a modelos:\n - Uso/cenários etc.\n - Baseadas em Casos de Uso:\n - Técnicas Cognitivas e Contextual:\n - Card sorting (Cognitivo), Etnografia (Contextual), etc. Técnicas Tradicionais - Entrevistas\n- Entrevista\n - Deve ser planejada e preparada cuidadosamente\n - Saber quem será entrevistado e porque\n - Definir o(s) objetivo(s) da entrevista\n - Preparar antecipadamente as questões que serão formuladas (ou parte delas) Entrevistas\n- Tipos de Questões nas Entrevistas:\n - Questões livres de contexto - focalizam o cliente, os objetivos globais e os benefícios\n - Quem está por trás da solicitação desse trabalho?\n - Qual é a solução?\n - Quem vai usar a solução?\n - Qual será o benefício econômico de uma solução bem sucedida?\n - Há outra fonte de informações importante para essa solução que você precisa?\n - Essas questões ajudam a identificar todos os envolvidos no software a ser construído, o objetivo do trabalho e possíveis alternativas p/ o desenvolvimento Entrevistas\n- Tipos de Questões nas Entrevistas:\n - Questões para percepção da solução\n - Como você caracterizaria \"boas\" saídas, que seriam geradas por uma solução bem sucedida?\n - Que problema(s) essa solução enfrentaria?\n - Você pode me mostrar ou descrever o ambiente no qual a solução será usada?\n - Tópicos especiais de desempenho ou restrições vão afetar o modo pelo qual a solução é abordada? Entrevista\n• Diretrizes para realização de entrevistas\n - Desenvolva um plano geral de entrevistas\n - Obtenha autorização para entrevistar\n - Planeje o tempo\n - Descubra o interesse do usuário\n - Use o estilo adequado de entrevistas\n - Relacionamento\n - Ponto de vista alternativo\n - Detalhamento e confirmação Entrevista\n• Problemas fundamentais de entrevistas: peopleware!\n - Entrevistar a pessoa errada (ou no momento errado)\n - Fazer perguntas erradas e obter respostas erradas\n - Criar ressentimentos Técnicas Tradicionais\n• Outras técnicas tradicionais para levantamento de informações\n - Questionários\n - Estudo de documentos relacionados Técnicas de elicitação em grupo\n• Brainstorming \n – Técnica básica para geração de ideias \n – Reuniões onde as pessoas sugerem e exploram ideias – sem que sejam criticadas! \n – Uma sessão consiste em duas fases:\n • Geração de ideias \n • Consolidação \n – Processo relativamente não estruturado \n • pode não produzir a mesma qualidade ou nível de detalhe de outros processos Técnicas de elicitação em grupo\n• Técnicas Facilitadas de Especificação de Aplicações (FAST) \n – Encorajam a criação de uma equipe conjunta de clientes e desenvolvedores, que trabalham juntos para:\n • Identificar problemas \n • Propor elementos da solução \n • Negociar diferentes abordagens \n • Especificar requisitos Técnicas de elicitação em grupo - \nTécnicas FAST\n• Abordagens mais populares de FAST: \n – JAD (desenvolvido pela IBM) \n – METHOD (Performance Resources Inc.)\n• Diretrizes básicas FAST \n – Uma reunião é conduzida com participação de engenheiros de software e de clientes \n – São estabelecidas regras para preparação e participação \n – É sugerida uma agenda (foco no problema a ser resolvido) \n – Um \"facilitador\" controla a reunião \n – É usado um mecanismo de definição Técnicas de elicitação em grupo\n• JAD – Joint Application Design\n – técnica para promover a cooperação, o entendimento e o trabalho em grupo entre usuários e desenvolvedores\n – Desenvolvedores ajudam usuários a formular problemas e explorar soluções\n – Usuários ganham um sentimento de envolvimento, posse e responsabilidade Técnicas de elicitação em grupo - JAD\n• Princípios básicos da técnica JAD\n – Dinâmica de grupo\n – Utilização de sessões de grupo facilitadas\n – Uso de técnicas visuais\n – Para aumentar a comunicação e entendimento\n – Manutenção do processo organizado e racional