verificação de requisitos do usuário, como fazer?

Minha pergunta é: como você pode verificar os requisitos dos usuários no início do processo de criação do software?

Eu mostro as especificações do usuário, protótipos, demos ... mas ainda assim os usuários esquecem de compartilhar alguns "detalhes insignificantes" sobre o processo ou regras e dados de negócios. O que aparece após o teste final como algumas "exceções realmente pequenas e raras" - que são transformadas em solicitação de alteração e acumulam muito trabalho.

Então, como você protótipo (ou verificação) dos requisitos dos usuários no início do projeto?

Use o desenvolvimento iterativo que força você a receber feedback frequente para o cliente / usuário.

Além disso, aumente a colaboração entre desenvolvedores e usuários removendo intermediários (geralmente inúteis), como gerentes de projeto ou mesmo analistas de negócios (o último pode ser muito necessário em domínios de negócios muito complexos).

São apenas algumas recomendações. Há muito a dizer sobre o assunto.

Eu sugiro que você dê uma olhada no Scrum . O que salvou minha vida.

Comece por não se livrar de intermediários, como analistas de negócios, porque eles são realmente treinados nisso. Se você não tiver essas pessoas, aceite que pelo menos um de seus desenvolvedores precisará desenvolver essa habilidade.

Em seguida, com o tempo, acumule um conjunto de instintos sobre o tipo de coisa que as pessoas costumam pedir no final dos projetos e os inicie em conversas no início do projeto. "O desconto será sempre o mesmo para todos os pedidos ou varia de acordo com o cliente?" "Todo usuário pode ver todos os relatórios ou apenas alguns para supervisores?" "O imposto sobre vendas é sempre o mesmo ou depende de onde o cliente está?" e assim por diante.

Além disso, tente escrever seu código para que ele fique isolado desses tipos de alterações que chegam atrasadas, porque algumas ainda chegam tarde, não importa o quê. Se você tiver lógica de negócios nos manipuladores de cliques dos seus botões, essas alterações serão realmente prejudiciais. Se você possui lógica de negócios em uma classe específica cujo nome facilita sua localização, e pode aproveitar o polimorfismo para, por exemplo, ter pedidos regulares e pedidos urgentes e cada pedido calcular sua própria taxa de remessa, a mudança que eles fizeram solicitado é muito menos doloroso.

Você não pode impedir alterações tardias. As leis mudam, os direcionadores de negócios (clientes, que vendas são promissoras, a grande idéia que o CEO tem ao ler algo no avião) mudam. Impeça o que puder e adote o resto, projetando seu código para ser alterável.

Você só precisa se certificar de que está cumprindo os critérios listados lá. Por exemplo, se diz "funcionalidade x deve estar disponível para todos os usuários", verifique se isso é verdade.

No início do processo de desenvolvimento, isso será difícil, mas mais próximo do prazo, mais você poderá verificar.

Talvez as coisas que você ainda não implementou, você pode verificar se elas estão nas considerações de design para saber que elas estão sendo consideradas durante o desenvolvimento inicial.

Lembro-me de estar em uma reunião de negócios e de ter um dos analistas de negócios dizendo que deve ser ótimo ser um desenvolvedor sempre com uma especificação fixa para trabalhar.

No mundo real, existem algumas coisas que ajudam muito nisso. O primeiro, é aceitar que esses detalhes de última hora são um fato da vida. a única especificação 100% completa do produto final é o código-fonte. Se o cliente já tiver isso, eles não precisam escrever, pois não?

A segunda coisa a fazer é tentar liberar ativamente os detalhes de especificação ausentes. agora você pode tentar fazer com que o cliente assine documentos de Caso de Uso de 300 páginas e outros mecanismos contratuais, mas no final, posso dizer com 100% de confiança, a melhor maneira é entregar software aos seus clientes. Faça com que eles o analisem, o usem, incentive-os ativamente a alterar a especificação de acordo com suas necessidades (e, quando apropriado, cobrar pelo trabalho). Mesmo quando apenas alguns dos recursos são implementados, o feedback do cliente é fundamental.

A terceira, ao ler a especificação, pense sobre o que causaria a alteração desse requisito e como você poderia lidar com variações. muitas vezes não é sensato projetar demais mudanças que possam não aparecer, mas ter um plano e, igualmente importante, não criar dificuldades extras, facilitará sua vida - e os pontos extras para manter a calma e ter confiança quando você diz "podemos lidar com isso até .... e levará cerca de 4 dias para fazer." inspirará outras pessoas a confiarem em você.

Eu acho que você não deve esquecer o outro lado. Para qualquer usuário, é difícil produzir uma lista completa de detalhes do que você deseja. Pense em você, você pensa em coisas novas o tempo todo.

É um trabalho difícil e incrível apresentar todos os requisitos e detalhes de algo sobre o qual você tem apenas uma vaga idéia. Eu acho que ninguém pode.

Eu tenho um livro aqui dos anos 70 chamado "por que os projetos de software falham". Quando leio em blogs e recebo revistas de TI, leio na capa "por que os projetos de software falham". E quando comparo o conteúdo do livro com as listagens atuais ... nada mudou. Desenvolvimento iterativo: sim, muitas variações e ajuda em algum nível. Mas depois de todo esse tempo, o conteúdo das revistas tem as mesmas capas. Se você não acredita em mim, desenterre algumas magz do passado e veja como você pode copiar e colar o texto no momento.

Esse problema não pode ser solucionado no final da TI. Estamos inventando novas ferramentas, processos, listas de verificação, esquemas de análise de requisitos, casos de uso (comerciais), estruturas de desenvolvimento, BPM, SOA, como você chama e ainda existe o mesmo problema ...

Você precisa otimizar isso em torno do 'especificador de requisitos'. Portanto, você precisa fornecer a essas pessoas as ferramentas adequadas, o que for para permitir que elas aumentem seu nível:

Então, por exemplo, para essas pessoas: padrões de especificação prontos para uso, contribuições de outros projetos e empresas que fazem a mesma cópia de seus requisitos e lições de resultado final, levam pessoas para lá que passaram pela sujeira e podem ajudar essa pessoa a especificar as coisas que causou os maiores problemas e não são "triviais", mas só podem ser aprendidos após fazê-lo (por exemplo, consultores técnicos seniores fazendo o mesmo em outras empresas), dê a essas pessoas ferramentas de compositor, para seguros, bancos, telecomunicações, etc. : não invente seus próprios processos, compre os processos genéricos imediatamente, etc ... eles precisam de ferramentas, assim como os desenvolvedores precisam de ferramentas, padrões e estruturas.

Não resolve, mas melhora significativamente. IMHO a melhoria deve ser em torno dessa área e não mais tarde no caminho.

Assim como um desenvolvedor, essas pessoas apenas tentam fazer o melhor que podem. Mas, diferentemente dos desenvolvedores para o seu campo, a maioria das coisas que tomamos como garantidas após 30 anos nem está presente nesse campo. Em geral, suas ferramentas são outlook, excel, word e um quadro. Seus processos são sessões de brainstorm. Muitas melhorias podem ser feitas neste campo. É claro que o problema é principalmente que eles estão "fora" da TI, de modo que os planos do CIO de melhorar a situação nesse campo caem em ouvidos surdos ... mas essa é outra questão: como "vender" isso.

Problema do ovo de galinha

O que você está enfrentando é chamado de problema do ovo da galinha na fase de análise de requisitos de software. Os clientes não compartilham os detalhes dos requisitos porque não conhecem a arquitetura de detalhes e os arquitetos não podem fazer a arquitetura de detalhes porque não conhecem os detalhes de todos os requisitos.

Solução Twin-Peak

No entanto, existe uma solução bem conhecida desse problema. Esse é o modelo de pico duplo. Nesse modelo, é necessário fazer várias iterações de comunicação com os clientes, começando de requisitos gerais para requisitos específicos, além de evoluir sua arquitetura de detalhes gerais para detalhes específicos.

Vantagens do modelo Twin-Peak:

• Os requisitos levam em consideração os limites do sistema
• Desenvolvimento rápido de alternativas de design
• Criação rápida de protótipos
• Desenvolvimento eficiente da arquitetura através do uso de soluções existentes
• A carga de trabalho de requisitos pode ser estimada a partir do primeiro plano aproximado de arquitetura
• Redução de custos porque requisitos "irreais" são identificados antes da solução em desenvolvimento
• Redução de risco no desenvolvimento

Referência

Você precisa informar aos usuários que quanto mais tarde um 'requisito' for identificado no projeto, mais ele custará. Eles podem decidir que realmente não precisam da mudança, afinal. Se eles insistirem nas alterações, mas recusarem os custos adicionais / atraso de tempo, você terá um problema que precisa ser negociado. Isso não será resolvido por meio de tecnologia ou planejamento, mas pelo gerenciamento de vendas e relacionamento com o cliente.

Colocar o software funcionando continuamente diante deles e exigir que eles se esforcem para usar / testar / avaliar é a sua melhor aposta. Eles não compreenderão completamente contratos, especificações, diagramas e histórias de usuários.

Isso faz parte do teste Joel. Agarre qualquer um que você encontrar para testar o software o máximo possível durante todo o processo de desenvolvimento.

Se você realmente deseja fazer o trabalho corretamente, antes de começar a trabalhar no código ou projetar uma arquitetura, sente-se com algumas das pessoas que serão os usuários do seu código (não com o gerenciamento deles ou com qualquer outra parte interessada de nível superior) e obtenha-os para mostrar como fazer o trabalho deles. Idealmente, faça o trabalho por um dia ou dois. Isso lhe dará uma compreensão do funcionamento do sistema atual e do tipo de pessoas que o estão fazendo. Também mostrará as frustrações que eles têm com o sistema atual e as coisas que estão atingindo sua produtividade. Você precisa ouvir todas as queixas e aborrecimentos diários também, o que pode significar que você deve fazer o necessário para garantir que o feedback seja interrompido por você ou por sua equipe de design, se a ideia de transmitir suas opiniões a outros membros da organização for provável inibir isso.

Para cada grupo de usuários, é necessário que alguém que trabalhe no desenvolvimento dessa parte do software faça a mesma coisa. Em seguida, todos poderão se encontrar e discutir o que aprendeu nas funções que você escolheu para verificar se há áreas de transição e como você pode facilitar as coisas para todos os envolvidos.

Não sugiro que isso substitua outros processos de coleta de requisitos, mas é um complemento que permite entender o que os usuários reais precisam do seu sistema. Qualquer que seja o gerenciamento que eles precisem, é provável que os gerentes e analistas de negócios não sejam os usuários reais do sistema, mas se você puder fazer o sistema funcionar bem para esses usuários, isso os tornará mais produtivos, tornando os gerentes felizes e felizes. fazendo sua empresa parecer boa.