Conseguir obter todos os requisitos do software

Fontes de Requisitos

Bons requisitos começam com boas fontes. Encontrar essas fontes de qualidade é uma tarefa importante e, felizmente, necessita de poucos recursos. Exemplos de fontes de requisitos incluem:

• Clientes
• Usuários
• Administradores e pessoal de manutenção
• Parceiros
• Experts do Domínio
  
• Analistas da Indústria
• Informações sobre competidores

Técnicas de Obtenção de Requisitos

Depois de você ter identificado as fontes, há um número de técnicas que podem ser usadas para obter requisitos. A seguir são descritas várias técnicas, seguidas por uma breve discussão de quando usar cada uma.

Para ter os requisitos no papel, você pode fazer um ou mais do seguinte:

• Conduzir uma sessão de brainstorming
• Entrevistar usuários
• Enviar questionários
• Trabalhar no ambiente alvo
• Estudar sistemas semelhantes
• Examinar sugestões e relatórios de problemas
• Conversar com equipes de suporte
• Estudar melhorias feitas pelos usuários
• Observar usos não intencionados
• Conduzir workshops
• Demonstrar protótipos aos stakeholders

A melhor idéia é escrever os requisitos rapidamente e então encorajar os usuários a corrigir e melhorá - los. Faça as correções e repita o ciclo. Faça na hora, mantenha simples e corrija rapidamente. Inicie com a melhor estrutura que você conseguir, mas espere continuar corrigindo durante o processo. Dicas de sucesso: Faça na hora, mantenha simples e corrija imediatamente.

Conduzir uma sessão de brainstorming

Brainstorming é uma pequena sessão em grupo em que todos podem dizer o que sentem ser mais importante para o 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.
• Uma vez que a informação seja obtida, remodele e combine idéias.

Entrevistar usuários

Contato face - a - face com usuários durante entrevistas individuais é a fonte primária de requisitos e um meio importante para você obter e validar 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.

Enviar questionários

Se encontros face - a - face forem possíveis, eles sempre serão preferíveis, porque eles fornecem melhores meios de descobrir o problema atrás do problema. Algumas vezes, no entanto, encontros face - a - face com stakeholders não são possíveis (quando desenvolvendo produtos para um mercado de consumidores, por exemplo). Nessas situações, considere usar questionários. Envie um conjunto de questões, possivelmente com respostas de múltipla escolha, para os stakeholders relevantes, e peça que respondam e o retornem a você. Dicas de sucesso: mantenha - o pequeno e estabeleça prazos.

Esta técnica possui a vantagem de fornecer bastante informação para análise estatística. Entretanto, as questões devem ser formuladas para serem claras e evitar as ditas "perguntas direcionadas" que influenciam as respostas.

Trabalhar no ambiente alvo

Experimente você mesmo o trabalho dos usuários. Trabalhar com usuários o ajuda a entender problemas que resistiram à soluções anteriores. Sistemas familiares desenvolvidos dessa maneira incluem inevitavelmente ferramentas para programadores, tais como editores interativos e compiladores, já que 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 maneira, ainda pode ser possível fazer um pouco mais do que simplesmente sentar e observar. 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 é frequentemente um sistema semelhante ou já existente. Algumas vezes, produtos e sistemas comparáveis contêm versões funcionais de boas idéias para resolver problemas de usuários. Você pode economizar o tempo perdido reinventando a roda observando sistema que já estão no mercado, sejam sistemas instalados no ambiente do usuário, sejam produtos criados por organizações rivais. Mesmo que eles resolvam problemas ligeiramente deferentes, frequentemente eles fornecem pistas valiosas sobre o que você precisa fazer.

Ouça quando um cliente pergunta por que um produto não pôde fazer algo que ele quer e mantenha uma lista com essas sugestões. Mais tarde, use - a para iniciar discussões com outros usuários. Você deveria ser capaz de obter alguns requisitos dessa maneira. Se não for, capture e guarde sugestões para uso futuro.

Você pode descrever para os usuários características selecionadas de outros produtos. Explique que o sistema é projetado para outra proposta mas contém uma característica interessante, e você imagina que ela ou algo similar os ajudaria. Algumas vezes, esses sistemas são descritos em documentos, tais como um contrato de outra organização ou um relatório gerencial. Frequentemente, esses documentos nunca foram vistos como requisitos formais foram meramente escritos para comunicar uma idéia recorrente. Defina um processo para ir da informação desorganizada à organizada.

Tal processo pode envolver as seguintes atividades:

• Leia o documento inteiro (várias vezes) para compreender o que o cliente quer e o que realmente foi escrito.
• Classifique todos os tipos de informação no documento (usuário, requisitos de sistema, elementos de design, planos, material de suporte, detalhes irrelevantes).
• Marque o texto original para separar requisitos.
• Encontre uma boa estrutura para cada um dos tipos diferentes de informação, tais como: um cenário para os requisitos de usuário, divisões funcionais para os requisitos de sistema, arquitetura para o design.
• Organize a informação para mostrar falhas e sobreposições. Sinta - se livre para adicionar elementos faltantes, mas confirme essas decisões com os usuários.
• Crie conexões entre as informações para mostrar aos designers exatamente o que os usuários querem.
• Convença o cliente a aceitar as novas informações como base para o contrato.

Examinar sugestões e relatórios de problemas

Requisitos podem se originar de sugestões e problemas de usuários. Uma maneira direta de encontrar requisitos é olhar as sugestões e problemas descritos primeiramente. Muitas organizações possuem alguma forma de relatar problemas ou defeitos em sistemas. Você pode pedir para olhar esses relatórios (e provavelmente haverá muitos). Organize - os em grupos para poder identificar as áreas chave que estão incomodando os usuários. Faça perguntas aos usuários sobre essas áreas para clarificar as reais necessidades dos usuários.

Conversar com equipes de suporte

A maioria das 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 engenheiros de suporte pode lhe dar boas direções aos requisitos, e economizar tempo. Converse também com a equipe de treinamento e equipes de instalação sobre o que 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, ou relacionado planilhas diferentes, ou desenhado gráficos que satisfazem as suas necessidades individuas. Você só precisa perguntar: Por que você adicionou isso? As respostas deles o ajudam a chegar ao coração do requisito real. Isso se aplica também a hardware e dispositivos não - computacionais. Por exemplo, um operador de torno mecânico pode ter manufaturado uma braçadeira especial ou um braço que não permite movimento da ferramenta além de certo ponto. Modificações desse tipo apontam algo errado com o produto existente, o que faz disso um requisito válido para a nova versão.

Observar usos não intencionados

As pessoas frequentemente usam coisas para propósitos que elas não foram projetadas. Essa é uma boa maneira de obter novas idéias e pensar em inovações. Por exemplo, um gerente de produto atento 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 agora estão disponíveis para uso doméstico.

Conduzir workshops

Workshops 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 efetivo em custos.

Workshops são mais rápidos e melhores na descoberta de requisitos do que outras técnicas, tais como enviar questionários. Você está formando a coleção certa de pessoas e fazendo com que elas corrijam e melhorem o documento de requisitos.

Um workshop é inerentemente caro pelo número de pessoas envolvidas, mas ele economiza uma grande quantidade de tempo. Se você puder definir o produto logo na primeira vez e cortar três meses de 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, assim as pessoas não são perturbadas pelos problemas do dia - a - dia. Telefones celulares deveriam ser desencorajados; organize para receber mensagens externamente. Tire vantagem das interações informais escolhendo um local para que as pessoas não vão para casa à noite ou separadamente. O exemplo na figura 1 exibe a lógica de um workshop de requisitos. Note que o workshop fornece o ambiente para se aplicar outras técnicas de obtenção de requisitos tais como brainstorming.

Figura 1: Conduzindo Workshops

Demonstrar protótipos aos stakeholders

Protótipos nos permitem ver imediatamente alguns aspectos do sistema. Mostrar aos usuários um protótipo simples pode provocá - los a fornecer boas informações de requisitos ou mudar de idéia sobre requisitos existentes. As técnicas descritas aqui o ajudam a obter idéias para requisitos. Protótipos e modelos são excelentes maneiras de apresentar idéias a usuários. Eles 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 usuários vêem o que você está sugerindo.

Uma apresentação pode usar uma seqüência de slides, roteiro, uma impressão de um artista ou mesmo uma animação para aos usuários a visão das possibilidades. Quando prototipando software, faça um rascunho das telas da interface com o usuário enfatizando que não há código e que o sistema não foi projetado nem especificado ainda (alerta: perigoso para os desavisados).

Essa prototipação objetiva fazer usuários expressar requisitos (faltantes). Você não está tentando vender aos usuários uma idéia ou produto, 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 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.

Qual técnica aplicar?

Qual técnica aplicar depende de um número de fatores, tais como:

• Disponibilidade e localização dos stakeholders
• Conhecimento da equipe de desenvolvimento sobre o domínio do problema
• Conhecimento dos clientes e usuários sobre o domínio do problema
• Conhecimento dos clientes e usuários sobre os métodos e processo de desenvolvimento

Se os stakeholders não estiverem co - localizados ou prontamente disponíveis, por exemplo, no de um produto sendo desenvolvido para o mercado de massas, técnicas tais como brainstorming, entrevistas e workshops que requerem contato face - a - face com os stakeholders podem ser difíceis ou impossíveis

Se os stakeholders estiverem disponíveis para encontros face - a - face, esta é uma situação muito melhor e quase todas as técnicas descritas, ou uma combinação delas, podem ser aplicadas. Nesse caso, a experiência no domínio e no desenvolvimento dos stakeholders e da equipe de desenvolvimento são fatores críticos na seleção da técnica apropriada.

A figura 2, adaptada de [HIC03], fornece um framework para determinar as técnicas apropriadas. Ela define quatro categorias principais de cliente ou experiência de usuário e equipe de desenvolvimento: "Fuzzy problem", "Selling/Teaching", "Catch up", e "Mature".

Figura 2: Seleção das Técnicas

Não há "resposta correta", mas estas diretrizes podem ajudá - lo a decidir que método usar:

• Catch-up: Entrevistas, trabalho no ambiente alvo
• Fuzzy: Brainstorming, workshops
• Mature: Quetionários, workshops, protótipos
• Selling/Teaching: protótipos