Como escrevo uma especificação funcional de maneira rápida e eficiente

Acabei de ler alguns artigos fabulosos de Joel sobre as especificações aqui . (Foi escrito em 2000 !!) Eu li todas as 4 partes, mas estou procurando algumas abordagens metódicas para escrever minhas especificações.

Eu sou o único desenvolvedor solitário, trabalhando neste aplicativo bastante complicado (ou família de aplicativos) para uma empresa financeira muito conhecida.

Eu nunca fiz algo tão sério, comecei a escrever algo como uma especificação ruim, uma visão geral de alguns tipos, e isso desperdiçou muito do meu tempo.

Também fiz três mockups para o meu cliente, para que eu tenha uma boa compreensão do que eles querem. Também disponibilizei uma visualização (um aplicativo de trabalho descartável com o fluxo de trabalho mais básico) e escrevi e testei apenas alguns dos sistemas mais básicos / básicos.

Eu acho que o erro que eu tenho cometido até agora não é escrever uma especificação detalhada, por isso estou conseguindo agora.

Então, a coisa toda é composta por

• Um site MVC (para administradores e visualização de dados)
• 2 módulos Silverlight (para 2 tarefas específicas)
• 1 aplicativo de desktop

Estou com pouco tempo, recursos e preciso fazer isso rápido, também, preciso garantir que esses caras leiam da mesma forma rápida e indolor.

• Então, como eu faço isso, eu estou procurando por dicas, coisas do mundo real, como vocês costumam fazer isso?
• Você faz uma simulação simulada de cada caixa de diálogo / formulário / página?

Estou pensando em criar um projeto fictício de formulários da Web do ASP.NET, em seguida, preencher arquivos HTML em pastas e fazer com que pareça minha estrutura de URL do MVC.

Depois, tenha uma seção nas especificações do site e escreva uma página para cada URL que tenho com um screenie.

Para o meu aplicativo Win Forms, criei um projeto demo do Win Form. Em seguida, colocaria uma caixa de diálogo ou estruturaria tudo o que faria no aplicativo real e depois a captura de tela?

Para alguns antecedentes desta questão. Eu sempre fui um tipo louco de ir para o código, que funcionou bem, mas para o aplicativo em que estou trabalhando, não é apenas complexo, é para uma grande e muito reputada empresa e tenho que obtê-lo certo!

(E está indo bem até agora, hoje eu fiz uma demonstração da versão de pré-visualização que muitas pessoas gostaram !! = D)

Se eu acertar o design inicial, também terei bons negócios com esta empresa, já há muitos pensando em novos recursos "impressionantes" pelos quais estão prontos para pagar.

Você leu a parte 2 do artigo ou a especificação de amostra ? Eles incorporam alguns princípios importantes ao escrever uma especificação.

• Não projete demais. O objetivo de escrever a especificação é forçá-lo a pensar em coisas importantes, como o que acontece quando há um erro e como você espera que o usuário interaja com o sistema. Você não precisa entrar em detalhes desordenados para obter algo em que possa trabalhar. Você precisa de detalhes, no entanto.
• É sobre comunicação. O objetivo da especificação é chegar a um acordo comum sobre o que precisa ser feito. Não é um documento rígido que requer força de lei. É uma ferramenta para ajudá-lo a entender melhor seu cliente e para entender melhor o que você deseja fazer por eles.

O melhor conselho é escrever o suficiente para que você fique claro sobre o que precisa fazer. Se você tiver perguntas abertas, documente-as na especificação e obtenha respostas do seu cliente. Depois de entender adequadamente o que é necessário, pare .

Se você não tomar cuidado, o documento terá vida própria. Ele deve ter um objetivo, não adicione nada ao documento que não se encaixe nesse objetivo. Deve ser fácil de manter. Se você tiver todos os diagramas de classe detalhados, além de outros detalhes que realmente pertencem a um teste de unidade, você abandonará o documento porque a manutenção é excessiva ou nunca concluirá o projeto.

Sobre a escrita

Escrever para as pessoas é difícil . De fato, as duas coisas mais difíceis de escrever são saber como começar e quando parar . No começo você só precisa fazer alguma coisa. Meu conselho para lidar com esses dois aspectos mais difíceis é:

• Conheça o seu público. Quem deveria ler as especificações? Se é só você e o cliente, é para quem você está escrevendo. Se você tiver alguém responsável pelos testes, também terá algumas anotações.
• Comece com a coisa de maior prioridade. Embora a autenticação seja importante, a tela de login é provavelmente a peça mais compreendida pela maioria das pessoas. Em vez disso, concentre-se no recurso que seus usuários mais precisam. Você sabe, aquela parte que lhes dá dinheiro e é a razão pela qual eles precisam do software.
• Preencha os detalhes à medida que as perguntas surgirem e você obtenha respostas. Mantenha as coisas realmente simples com desenhos de guardanapo, se necessário, até que o cliente esteja satisfeito com o arranjo. É importante saber quais informações estão envolvidas e como elas serão usadas.
• Pare quando adicionar mais não agrega valor. Existem alguns detalhes que você simplesmente não deseja em uma especificação. Você precisa saber quando tem a coisa certa. Você não precisa saber que existe uma variável dentro de um método chamado "albaquerque". Isso é código fonte, não coisas de especificação.