Como fazer uma ótima especificação funcional

Vou iniciar um pequeno projeto paralelo muito em breve, mas desta vez não quero apenas o pequeno modelo de domínio UML e diagramas de casos que costumo fazer antes da programação, pensei em fazer uma especificação funcional completa. Existe alguém que tenha experiência em escrever especificações funcionais que possam me recomendar o que eu preciso adicionar? Como seria a melhor maneira de começar a prepará-lo? Aqui vou escrever os tópicos que acho mais relevantes:

• Objetivo
• Visão Geral Funcional
• Diagrama de Contexto
• Fatores críticos de sucesso do projeto
• Escopo (entrada e saída)
• Premissas
• Atores (fontes de dados, atores do sistema)
• Diagrama de casos de uso
• Diagrama de fluxo de processo
• Diagrama de atividades
• Requisitos de segurança
• Requisitos de desempenho
• Requisitos especiais
• Regras do negócio
• Modelo de domínio (modelo de dados)
• Cenários de fluxo (sucesso, alternativa…)
• Horário (Gerenciamento de tarefas)
• Metas
• Requisitos de sistema
• Despesas esperadas

O que você acha desses tópicos? Devo adicionar outra coisa? ou talvez remover alguma coisa?

Encontrei todas as respostas e gostaria de agradecer a todos pelas informações úteis.

Estou fazendo esse projeto paralelo para uma empresa, e eles observam de mim um fluxo constante de comunicação e precisarei explicar por que faço tudo, porque precisarei administrar os recursos que eles me fornecerão. Esta será a minha primeira especificação de funções e, como eu disse, quero que seja útil, não apenas grande e inútil. Eu acho que isso é algo que precisa ser feito, mas quero fazê-lo da maneira que será mais útil para mim e minha equipe. É ruim que eu não tenhamos um gerente, por isso também preciso cuidar de algumas tarefas administrativas ...

Em relação à programação ágil, acho que isso é 100% compatível com a abordagem ágil. Sou um programador ágil e sinceramente fiquei mais confiante quando alguém já pensou por mim. Eu ainda sou Junnior, mas trabalhei antes como desenvolvedor Web de Tapeçaria em outros projetos, onde a organização era um caos total.

Não concordo que estou fazendo uma abordagem em cascata, acho que estou apenas tentando definir alguns limites que tornarão o projeto mais fácil quando o desenvolvimento começar.

O que você sugere é bom do ponto de vista dos puristas de Engenharia de Sistemas.

(Haverá alguns devotos ágeis que acham que tudo é exagerado ... e você deve sair e fazer coisas com as críticas usuais, etc.).

No entanto, você precisa levar em consideração o que está fazendo e para quem está fazendo.

Fazer um projeto para si mesmo é diferente de fazer para outra pessoa - por dinheiro.

Quando você trabalha para outra pessoa (em uma empresa ou sob contrato), os ÚNICOS meios de comunicação estão falando e escrevendo. (Por fim, haverá um produto ou resultado que poderá ser avaliado.)

O objetivo principal de uma especificação é tentar reduzir o custo de fazer correções e alterações que virão mais tarde. Você pode ter visto os gráficos mostrando o custo de fazer correções em diferentes estágios de um projeto, é algo como isto:

• Uma correção feita para uma ideia idiota custa US $ 1

• Uma correção feita quando a idéia idiota a transformou em uma especificação (que precisa ser atualizada) custa US $ 10

• Uma correção feita quando você constrói um protótipo custa US $ 100

• Uma correção feita no momento em que você está aceitando antes do envio custa US $ 1000

• Uma correção feita depois que você envia e irrita seus clientes custa US $ 10000.

Portanto, o que você escreve em uma especificação é muito importante.

Argumentar que você não deve ter nenhuma especificação é ingênuo, tolo e provavelmente perigoso.

Um dos maiores problemas que você tem ao escrever uma especificação é saber quando você foi longe demais. Isso varia dependendo do tamanho do projeto. Por exemplo, um projeto que leva de 1 a 2 pessoas por ano deve ter entre 2 e 4 SEMANAS no total gasto em especificações ... o que inclui a investigação de viabilidade ... as especificações a serem escritas pelas pessoas que realmente fazem o trabalho não é de algum tipo de analista de alta falutina que não conhece os detalhes sangrentos. Um projeto de 10 pessoas a 2 anos precisa de muito mais tempo.

Agora, para alguns comentários sobre seus vários pontos:

• Objetivo

SIM, escreva isso. Mantenha-o em 1-2 parágrafos, no máximo em 1/2 página.

• Visão Geral Funcional

TALVEZ. Somente se agregar valor a todo o resto.

• Diagrama de Contexto

ESSENCIAL. Mostra TODAS as entradas e saídas. Mostra o contexto. Você pode (e deve) gastar um tempo razoável nisso.

• Fatores críticos de sucesso do projeto

TALVEZ. Certamente, se o projeto atender aos requisitos, será um sucesso. Eu acho que isso não é realmente necessário.

• Escopo (entrada e saída)

NÃO. Seu diagrama de contexto faz isso.

• Premissas

SIM. Tente e seja breve.

• Atores (fontes de dados, atores do sistema)

TALVEZ. Isso me parece um pouco técnico de design, que não deve estar em uma especificação FUNCIONAL.

• Diagrama de casos de uso

TALVEZ. Coloque isso (estes) em um apêndice. Explique com palavras. Tente mantê-los em um número pequeno. Vi sugestões de que um projeto não deveria ter mais de 8 casos de uso explicados em detalhes. Não cubra todos os caminhos "infelizes" ou você nunca terminará.

É muito raro qualquer parte de s / w ter um único caso de uso / diagrama de casos de uso.

• Diagrama de fluxo de processo

TALVEZ. Somente se agregar um valor significativo, você estará perdendo seu tempo.

• Diagrama de atividades

TALVEZ. Somente se agregar um valor significativo, você estará perdendo seu tempo.

• Requisitos de segurança

SIM - se relevante.

• Requisitos de desempenho

SIM - obrigatório. Devo dizer o que a coisa deve fazer (e com que nível de desempenho).

• Requisitos especiais

TALVEZ - se houver algo especial.

• Regras do negócio

TALVEZ - se útil.

• Modelo de domínio (modelo de dados)

TALVEZ - se útil.

• Cenários de fluxo (sucesso, alternativa…)

TALVEZ - se útil.

• Horário (Gerenciamento de tarefas)

NÃO. Não é isso que deveria estar em uma especificação. É sobre programação, planejamento etc.

• Metas

TALVEZ. Objetivos não são requisitos, são coisas vagas e fofas, que não servem para nada, que servem para enlamear as águas. Tente e evite.

• Requisitos de sistema

SIM. Essencial. Diz o que a coisa deve fazer.

• Despesas esperadas

NÃO. Parte do planejamento e gerenciamento, não os requisitos do que você está criando.

Explicação: Escrevo especificações de produtos, software e sistemas complexos há mais de 15 anos. Todas as coisas comerciais. Principalmente comercialmente bem sucedido e fez muito dinheiro para vários empregadores. Incluindo a especificação para o desenvolvimento Agile s / w, em que você ainda precisa de uma especificação antes de entrar no desenvolvimento. O desenvolvimento REAL pode ser feito no processo que você quiser, mas no final você deve ter três coisas para obter sucesso:

1. Saiba o que você quer fazer. E ESCREVA-O PARA BAIXO. (Isso é uma especificação.)

2. Faça coisas para atender o número 1 acima.

3. Faça algum nível de teste de aceitação da coisa em relação à especificação (que é essencialmente "você fez o que você disse que faria").

Há três coisas a serem lembradas

1) Você tem que começar de algum lugar

Você identificou qual é o problema que este projeto está tentando resolver? Você também pode começar dizendo "Aqui estão as coisas que este projeto não estaria completo se não pudesse fazer". Também vi alguns projetos (alguns bem-sucedidos, outros nem tanto) projetar a tela principal e preencher os espaços em branco a partir daí.

2) Você tem que terminar em algum lugar

Você pode especificar as coisas para o inferno, mas se você realmente nunca fizer algo, tudo o que você fez é desperdiçar muito tempo e papel e ignorar sua esposa e filhos por sete semanas. (Já fez isso, alguém?) Portanto, certifique-se de definir alguns limites sobre até onde suas especificações vão. É uma especificação técnica e também uma funcional?

3) Você tem que ir do início ao fim

Não comece obtendo um requisito importante e preenchendo todos os detalhes antes de obter o segundo requisito principal, pelo menos no esquema. Crie suas especificações horizontalmente primeiro e depois verticalmente. Caso contrário, quando você perceber alguns pequenos detalhes do requisito um, impossibilitando todo o requisito dois, você terá alguns problemas importantes.

Eu dividiria sua lista em três partes: o que os usuários se importam, o que os programadores se preocupam e o que os gerentes se preocupam. Deixe um programador fazer sua parte e um gerente faça sua parte. O programador provavelmente precisará fornecer estimativas para partes do projeto ao gerente e ao gerente para fornecer as restrições orçamentárias ao programador (isto é, não pode demorar mais de X semanas). Se todos (cliente, gerente, programador) concordarem, será um sinal verde e iniciar o projeto. Para o programador, muitas pessoas cocô-cocô especificações, às vezes com razão. Eu especificaria apenas as partes em que duas ou mais partes estão se comunicando (por exemplo, cliente-servidor). De resto, pratique alguma forma de TDD com base nas histórias de usuários. Uma linha para o cliente também é benéfica para obter histórias.

Histórias de usuários

• Objetivo geral Visão geral funcional dos objetivos
• Atores (fontes de dados, atores do sistema)
• Diagrama de casos de uso
• Diagrama de fluxo de processo
• Diagrama de atividades
• Diagrama de Contexto
• Regras do negócio
• Requisitos especiais
• Requisitos de desempenho

Gerente

• Fatores críticos de sucesso do projeto
• Despesas esperadas
• Cenários de fluxo (sucesso, alternativa…)
• Horário (Gerenciamento de tarefas)

Programador

• Requisitos de segurança
• Modelo de domínio (modelo de dados)
• Requisitos de sistema

Além disso, provavelmente não existe uma receita perfeita para todos os tipos de problemas de software. Para um aplicativo do Facebook, você provavelmente deseja fazer uma demonstração antecipada e frequente. Para um sistema de orientação de mísseis, provavelmente não tanto ;-)

A preparação de todos esses documentos pode levar meses! Parece uma espécie de abordagem em cascata para mim.

Não posso sugerir a adição de mais alguma coisa à sua lista, a menos que você tire algumas delas. Eu acho que os artefatos a serem produzidos dependerão da cultura da sua organização e do conjunto de habilidades dos desenvolvedores.

Não há especificação funcional melhor que um protótipo funcional, mas fugaz, justamente por causa dos problemas com uma abordagem em cascata.