Diretriz: Técnicas Para Obtenção de Requisitos |  |
Esta diretriz descreve várias técnicas para obtenção de requisitos.
Relacionamentos
Elementos Relacionados | Definir a Visão Encontrar e Descrever os Requisitos Requisitos
Descrição Principal
# Fontes de Requisitos Bons requisitos começam com boas fontes. Encontrar essas fontes qualificadas é uma tarefa importante e, felizmente, necessita de poucos recursos. As fontes primárias de requisitos são os Stakeholder, então comece identificando-os a partir destes candidatos: Clientes Usuários Administradores Pessoal de manutenção Parceiros Solicite a cada Stakeholders que identifique outros Stakeholders. Ao "descascar a cebola" desta forma, você pode identificar rapidamente todos os Stakeholders e assim não perder importantes perspectivas e requisitos associados. Isto irá ajudá-lo a identificar e resolver os requisitos conflitantes, o mais cedo possível. Estas são outras possíveis fontes de idéias para requisitos: Peritos do Domínio Analistas da Indústria Informações sobre competidores O último item muitas vezes inclui informações sobre o sistema atual que os concorrentes estão usando para resolver o problema de negócio. # Técnicas Para Obtenção de Requisitos Depois de você ter identificado as fontes, existem várias técnicas que você pode usar para obter os requisitos (veja também [TEL06]). Entretanto, é importante reconhecer que a obtenção de requisitos é um processo iterativo, e não existe uma técnica única que seja universalmente aplicável [HIC03]. Dicas de Sucesso: Faça na hora, mantenha simples e itere. Capture os requisitos e então colabore com os Stakeholders para corrigi-los e melhorá-los. Você pode capturar os requisitos em uma ou mais das seguintes formas: Conduzir uma sessão de brainstorming Entreviste os usuários Trabalhar no ambiente alvo Estudar sistemas semelhantes Examinar informes de problemas e sugestões Conversar com equipes de suporte Estudar melhorias feitas pelos usuários Procurar por usos não intencionados Conduzir workshops colaborativos Demonstrar protótipos aos Stakeholders ## Conduzir uma sessão de brainstorming O Brainstorming é uma pequena sessão em grupo onde todos os participantes podem dizer o que sentem ser mais importante em relação ao tópico em discussão. Depois, um facilitador lidera o grupo na organização e priorização dos resultados. As seguintes regras básicas para brainstorming asseguram melhores resultados: Inicie declarando claramente o objetivo da sessão de brainstorming. Gere tantas idéias quantas forem possíveis. Deixe sua imaginação viajar. Não permita críticas ou debates enquanto você está obtendo informações. Após você ter obtido as informações, remodele e combine as idéias. ## Entreviste os usuários O contato face-a-face com os usuários durante entrevistas individuais é a principal fonte de requisitos e um meio importante para obter e validar os requisitos. Lembre que essa não é a única técnica possível, e que você pode conduzir entrevistas de várias formas diferentes. Desenvolva um repertório de estilos para se adequar a diferentes situações. A menos que você mesmo vá fazer uso do sistema, você precisará de um esforço extra para entender e experimentar o problema do usuário para descrevê-lo claramente e corretamente. Comece com entrevistas não estruturadas para obter uma compreensão do ambiente de trabalho. Pergunte aos Stakeholders sobre os seus trabalhos e os problemas que eles enfrentam. Entrevistas estruturadas, que usam um conjunto de questões preparadas, podem ser feitas posteriormente para preencher as lacunas do seu conhecimento. ## Trabalhar no ambiente alvo Experimente você mesmo o trabalho dos usuários. Trabalhar com os usuários ajuda a entender os problemas que resistiram as soluções anteriores. Sistemas familiares que foram desenvolvidos dessa forma incluem inevitavelmente ferramentas para programadores, tais como editores interativos e compiladores, porque os desenvolvedores naturalmente tem a expertise na área e o desejo de resolver seus próprios problemas. Seria bom ver a mesma dedicação direcionada na resolução de problemas em outras áreas também. Quando o trabalho não pode ser facilmente experimentado dessa forma, ainda pode ser possível fazer um pouco mais do que simplesmente sentar e observar. Os usuários podem comentar sobre o que eles estão fazendo, quais são os problemas e o que eles gostariam de ter para deixar o trabalho mais fácil. ## Estudar sistemas semelhantes O ponto inicial para muitos projetos é normalmente um sistema semelhante ou já existente. Algumas vezes, produtos e sistemas comparáveis contêm versões funcionais de boas idéias para resolver os problemas dos usuários. Você pode economizar tempo e evitar a reinvenção da roda, observando sistemas que já estão no mercado, sejam sistemas instalados no ambiente do usuário, ou produtos criados por organizações concorrentes. Mesmo que eles resolvam problemas ligeiramente deferentes, normalmente eles fornecem pistas valiosas sobre o que você precisa fazer. ## Examinar informes de problemas e sugestões Os requisitos podem se originar de sugestões de mudanças e problemas de usuários. Uma forma direta de encontrar requisitos é olhar as sugestões e problemas da forma que foram inicialmente descritos. Muitas organizações possuem alguma forma de relatar problemas ou defeitos em sistemas. Você pode pedir para olhar esses informes (e provavelmente haverá muitos). Organize-os em grupos para poder identificar as principais áreas que estão incomodando os usuários. Faça perguntas aos usuários sobre essas áreas para esclarecer as reais necessidades deles. Se existir uma Lista de Itens de Trabalho de uma versão anterior, ou mesmo de um projeto semelhante, revise-a para encontrar potenciais requisitos que possam ser aplicados ao projeto de desenvolvimento atual. Se você tiver sorte, você poderá re-utilizar um pouco disso também. ## Conversar com equipes de suporte A maioria das grandes organizações de vendas possui um help desk que mantém uma lista de problemas e soluções, e engenheiros de suporte que solucionam os problemas. Muitas organizações possuem estruturas similares para suportar suas próprias operações. Conversar com o pessoal de help desk e com os engenheiros de suporte pode lhe dar um bom direcionamento para os requisitos, e economizar tempo. Converse também com a equipe de treinamento e as equipes de instalação sobre o que os usuários acham mais problemático. ## Estudar melhorias feitas pelos usuários Esta é uma excelente fonte de requisitos. Usuários de uma planilha padrão da companhia podem ter adicionado alguns campos, combinado planilhas diferentes ou desenhado gráficos que satisfaçam as suas necessidades. Você só precisa perguntar: Por que você adicionou isso? As respostas lhe ajudarão a chegar ao coração do requisito real. ## Procurar por usos não intencionados As pessoas normalmente usam as coisas para propósitos que os projetistas não intencionaram. Essa é uma boa forma de obter novas idéias e pensar em inovações. Por exemplo, um gerente de produto observador notou que um engenheiro ficava no escritório até mais tarde para usar um sistema de design auxiliado por computador para projetar uma nova cozinha para sua casa. Produtos comerciais baratos já estão disponíveis para uso doméstico. ## Conduzir workshops colaborativos Os Workshops colaborativos podem agregar um bom conjunto de requisitos rapidamente. Entre dois e cinco dias, você pode criar um conjunto de requisitos, e então revisá-los e melhorá-los. Se todos no workshop tentarem estimar o custo e valor de cada requisito, o documento se torna muito mais útil e com custos efetivos. Os Workshops colaborativos são melhores e mais rápidos para a descoberta de requisitos do que quaisquer outras técnicas, tais como entrevistas pessoais. Você está reunindo o grupo certo de pessoas e fazendo com que elas corrijam, melhorem e cheguem a um consenso a respeito dos seus requisitos. Um workshop é inerentemente caro por causa da quantidade de pessoas envolvidas, mas ele economiza uma quantidade de tempo significante. Se você puder definir o produto logo na primeira vez e cortar três meses para obtenção de requisitos, a economia pode ser enorme. O workshop tem que ser completamente organizado para tirar vantagem do tempo das pessoas. Escolha um local tranqüilo para o workshop, de forma que as pessoas não sejam perturbadas pelos problemas do dia-a-dia. Desencoraje os telefones celulares; porem organize o recebimento de mensagens. Tire vantagem das interações informais escolhendo um local onde as pessoas não tenham que sair separadamente ou ir para casa a noite. O exemplo na figura abaixo mostra a lógica de um workshop de requisitos. Note que o workshop fornece ambiente para aplicar outras técnicas de obtenção de requisitos tais como brainstorming. Conduzindo Workshops ## Demonstrar protótipos aos Stakeholders Os protótipos e os modelos são excelentes formas de apresentar idéias aos usuários, porque eles permitem as pessoas verem imediatamente alguns aspectos do sistema. Mostrar aos usuários um protótipo simples pode estimulá-los a fornecer boas informações sobre requisitos ou mudar de idéia sobre os requisitos existentes. Os protótipos podem ilustrar como uma abordagem pode funcionar, ou dar aos usuários uma visão do que eles podem ser capazes de fazer. Mais requisitos podem emergir quando os usuários vêem o que você está sugerindo. Uma apresentação pode usar uma seqüência de slides, um story board, uma impressão de um artista ou mesmo uma animação para dar aos usuários uma visão das possibilidades. Quando da prototipagem de software, faça uma maquete das telas da interface com o usuário enfatizando que não existe código e que o sistema não foi projetado nem especificado ainda. Cuidado: Uma maquete pode gerar expectativas difíceis de serem atendidas. Esta prototipagem objetiva fazer com que os usuários mencionem o que pode se transformar em requisitos faltantes. Você não está tentando vender aos usuários uma idéia ou produto. Ao invés, você está descobrindo o que eles querem realmente. Ver um protótipo, que invariavelmente está errado em alguns aspectos e correto em outros, é um poderoso estímulo para os usuários começarem a dizer o que eles querem. Eles podem apontar vários problemas com o protótipo. Isso é excelente porque cada problema leva a um novo requisito.
Este programa e o material que o acompanha são disponibilizados sob a Eclipse Public License v1.0 que acompanha esta distribuição. Direitos Autorais do OpenUP.