Como é que é importante para escrever especificações funcionais?

Question

especificações funcionais

Eu nunca escrevi, eu prefiro a saltar para o código e design de coisas como eu ir. Até agora, a sua funcionou bem, mas para um projeto pessoal recente que eu estou escrevendo algumas especificações que descrevem todas as características do produto, e como eu deveria 'trabalho', sem entrar em detalhes de como ele será implementado, e estou achando muito valioso.

Quais são seus pensamentos, você escreve especificações ou você apenas começar a programar e planejar como você vai, e que a prática é melhor?

Answer 1

Se você está dirigindo de sua casa para o supermercado mais próximo, você provavelmente não precisa de um mapa. Mas ...

Se você estiver dirigindo para um lugar que você nunca esteve antes em outro estado, você provavelmente fazer.

Se você estiver dirigindo em torno de forma aleatória para a diversão de condução, você provavelmente não precisa de um mapa. Mas ...

Se você está tentando chegar a algum lugar da forma mais eficaz (minimizar a distância, minimizar o tempo, fazer três específica paradas ao longo do caminho, etc.), você provavelmente fazer.

Se você estiver dirigindo sozinho e pode demorar tanto quanto você gosta, parando qualquer momento você vê algo interessante ou a reconsiderar seu destino ou rota, você pode não precisar de um mapa. Mas ...

Se você estiver dirigindo, como parte de um comboio, e todos necessidade de fazer comida e hospedagem durante a noite pára juntos, e necessidade de chegar junto, você provavelmente fazer.

Se você acha que eu não estou falando de programação, você provavelmente não precisa de uma especificação funcional, cartões de história, narrativa, CRCs, etc. Mas ...

Se você acha que eu sou, você pode querer considerar, pelo menos, uma das opções acima.

; -)

Answer 2

Para alguém que "salta para o código" e "projeto [s] como eles vão", eu diria que escrever qualquer coisa, incluindo uma especificação funcional é melhor do que seus métodos atuais. Uma grande quantidade de tempo e esforço pode ser salvo se você tomar o tempo para pensar sobre isso e projetá-lo antes mesmo de começar.

• Requisitos ajudam a definir o que você precisa fazer.
• Projeto ajuda a definir o que você está pensando em fazer.
• define Documentação do usuário o que você fez.

Você verá que a maioria dos lugares terá alguma variação destes três documentos. A especificação funcional pode ser aglomeradas no documento design.

Eu recomendo a leitura Desenvolvimento Rápido se você não está convencido. Você verdadeiramente pode começar o trabalho feito mais rápido se você levar mais tempo para planejar e design.

Answer 3

Jumping "direto para o código" para grandes projetos de software quase certamente levam ao fracasso (como immediatley começando colocam tijolos para construir uma ponte faria).

Os caras no 37 Signals diria que é melhor para escrever um pequeno documento em papel do que escrever um especificação complexa. Eu diria que isso poderia ser verdade para zombar-se rapidamente novos sites (onde o design ea idéia poderia conduzir melhor do que um esquema rígido), mas nem sempre aceitável em outras situações da vida real.

Basta pensar no (mesmo legal,) importância de um documento de especificação assinado pelo seu cliente pode ter.

O moral provavelmente é:. Ser flexível , e um plano com especificações funcionais e técnicas tanto quanto você precisa , de acordo com o cenário de seu projeto

Answer 4

Para hacks e pequenos utilitários one-off, não se incomode.

Mas se você estiver escrevendo um aplicativo sério, grande e tem clientes exigentes e tem que correr por um longo tempo, é uma obrigação. grandes artigos de leitura Joel sobre o assunto -. eles são um bom começo

Answer 5

Eu faço as duas coisas, mas eu aprendi alguma coisa de Test Driven Development ...

Se você entrar em codificação com um roteiro que você vai chegar ao fim da viagem muitíssimo mais rápido do que você vai se você só começar a andar na estrada sem ter qualquer idéia de como ele vai garfo no meio.

Você não tem que anotar cada detalhe do que cada função que vai fazer, mas defini-lo básico para que maneira você sabe o que deve ser feito para fazer tudo funcionar bem juntos.

Tudo o que está sendo dito, eu precisava para escrever uma série de manipuladores de exceção ontem e eu só mergulhou direita sem tentar arquiteto-lo em tudo. Talvez eu devesse reler meu próprio conselho;)

Answer 6

O que muitas pessoas não querem admitir ou perceber é que o desenvolvimento de software é uma disciplina de engenharia. Muita coisa pode ser aprendida sobre a forma como eles abordam as coisas. Mapeando o que o seu vai fazer em um aplicativo não é necessariamente vital em pequenos projectos, como é normalmente mais fácil ir rapidamente para trás e corrigir seus erros. Você não ver quanto tempo é desperdiçado em relação ao escrever o que o sistema vai fazer em primeiro lugar.

Na realidade em grandes projetos é quase necessário ter roteiro de como o sistema funciona e o que ele faz. Chamá-lo de uma especificação funcional se quiserem, mas normalmente você tem que ter algo que pode mostrar-lhe porquê etapa b segue passo a. Todos nós pensamos que podemos pensar-lo on the fly (eu sou definitivamente culpado disso também), mas na realidade ela nos causa problemas. Pense de novo e perguntar quantas vezes você encontrou alguma coisa e disse para si mesmo "Cara, eu gostaria de ter pensado nisso antes?" Ou alguém ver é o que você fez, e mostrou-lhe que você poderia ter tomar 3 etapas para realizar uma tarefa onde você tirou 10.

Colocá-lo no papel realmente força você a pensar sobre o que vai fazer o seu. Uma vez que está no papel não é um pensamento nebuloso mais e então você pode olhar para ele e avaliar se o que você estava pensando realmente faz sentido. Alterar um documento de uma página é mais fácil do que mudar 5000 linhas de código.

Answer 7

Se você estiver trabalhando em um XP (ou similar) ambiente, você vai usar histórias para orientar o desenvolvimento junto com lotes de unidade e testes de usabilidade corredor (eu tenho bebido o Kool-Aid , eu acho).

No entanto, há uma área onde uma especificação é absolutamente necessário: ao coordenar com uma equipe externa. Eu tinha um projeto com uma grande companhia de seguros onde se necessário para ter um acordo sobre certos comportamentos do programa, alguns aspectos do design de banco de dados e uma série de layouts de arquivos. Sem o spec, eu era ampla aberto a uma interpretação criativa do que havia prometido. Estas eram pessoas boas - eu confiava neles e gostei de trabalhar com eles. Mas ainda assim, sem essa especificação, teria sido uma marcha da morte. Com o spec, eu sempre poderia apontar onde eles haviam desviado do acordados para o layout ou onde eles estavam pedindo para trabalhos por encomenda adicional ($$!). Se estiver trabalhando com uma relação semi-antagônica, a especificação pode salvá-lo de ainda pior:. Uma ação

Oh sim, e eu concordo com Kieveli: "salto direito de código" quase nunca é uma boa idéia

.

Answer 8

Eu diria que totalmente "depende" do tipo de problema. I tendem a perguntar a mim mesmo que estou escrevendo isso para o bem dela ou para as camadas acima de você. Eu também tinha discutido isso e minha experiência pessoal diz, você deve uma vez que mantém o projeto em andamento com as expectativas (em vez de ir para fora do curso).

Answer 9

Eu gosto de decompor quaisquer problemas não triviais livremente no papel primeiro, em vez de saltar para o código, por uma série de razões;

• O material que eu escrever no papel não tem que compilar ou faz qualquer sentido para um computador
• Eu posso trabalhar em níveis arbitrários de abstração em papel
• I pode adicionar fotos e diagramas muito facilmente
• eu posso pensar e depurar um conceito muito rapidamente

Se o problema que eu estou lidando com é susceptível de envolver tanto uma quantidade significativa de tempo, ou um número de outras pessoas, vou escrevê-la como uma especificação funcional contorno. Se eu estou sendo pago por alguém para desenvolver o software, e não há qualquer possibilidade de ambiguidade, vou acrescentar o detalhe extra suficiente para remover esta ambiguidade. Eu também gosto de usar esta documentação como um ponto de partida para o desenvolvimento de casos de teste automatizados, uma vez que o software foi escrito.

Dito de outra forma, eu escrevo o suficiente de uma especificação funcional para compreender adequadamente o software Estou-me a escrever, e para resolver quaisquer ambiguidades possibile para qualquer pessoa envolvida.

Answer 10

Eu raramente sentem a necessidade de uma especificação funcional. OTOH eu sempre tenho o usuário responsável pela característica um telefonema de distância, para que eu possa sempre consultá-los para requisitos funcionais como eu ir.

Para mim uma especificação funcional é mais uma ferramenta de política do que técnica. Eu acho que uma vez que você tem uma especificação que você pode sempre culpar a especificação se você descobrir mais tarde problemas com a implementação. Mas quem a culpa é realmente de nenhum interesse para mim, o problema ainda estará lá mesmo se você encontrar um bode expiatório, melhor então para revisitar a implementação e tentar fazê-lo direito.

É praticamente impossível escrever uma boa especificação, porque você realmente não sei o suficiente de qualquer problema ou as ferramentas ou futuras mudanças no ambiente para fazer isso direito.

Assim, eu acho que é muito mais importante para adaptar uma abordagem ágil para o desenvolvimento e dedicar recursos suficientes e tempo para revisitar e refatorar que você vá.

Answer 11

É importante não para escrevê-los: está lá Nada funcional sobre um Funcional Spec