Pergunta

Basicamente, estou procurando bons modelos para escrever especificações técnicas e funcionais em um projeto ou solicitação de trabalho.

O que você usa?Quão profundo você chega ao escrever as especificações?Quaisquer dicas gerais adicionais que você possa fornecer serão apreciadas.

Minha empresa precisa muito disso.Trabalho para uma empreiteira e no momento não usamos esses documentos.

EDITAR: Eu li a opinião de Joel sobre Especificação indolor, gostei muito, mas há alguma outra opinião :)

Foi útil?

Solução

Sobre dicas gerais;

Estamos implementando um processo de

1) Declaração de Requisitos de Negócios (BRS)

2) Especificação Funcional

3) Especificação técnica

O BRS cobre quais são os problemas de negócios e quais são os requisitos em torno de soluções, testes, segurança, confiabilidade e entrega.Isso define o que constituiria uma solução bem-sucedida.

A especificação funcional detalha o que é necessário, como deve ser a aparência, o tamanho dos campos, etc.

As especificações técnicas detalham a origem dos dados e qualquer código complicado que possa precisar ser considerado.

O cliente possui os requisitos.Os desenvolvedores possuem as especificações técnicas, e as especificações funcionais são um meio-termo.O teste é feito de acordo com as especificações técnicas (geralmente testes de unidade), depois com as especificações funcionais (geralmente testes de sistema) e depois com os requisitos (UAT).

A parte importante disso (e com a qual estamos lutando) é que os desenvolvedores ainda precisam entregar as especificações funcionais e os requisitos de negócios originais.Na realidade, as especificações funcionais e técnicas existem apenas para maior clareza.

Resumindo, minha principal dica é primeiro definir o processo que você deseja implementar.Em seguida, busque o acordo de todas as partes envolvidas no processo proposto e, em seguida, trabalhe nos modelos que se ajustem.Os modelos em si são apenas uma pequena parte da alteração que você deseja fazer.

Outras dicas

Não é um modelo, mas Joel escreveu um alguns artigos ao escrever uma especificação funcional.Ele também tem amostra aqui.

Você pode comprar modelos no ieee e em outros lugares, mas sempre acabei fazendo os meus próprios.

Para uma especificação técnica, "Código completo"de Steve McDonnell tem uma boa lista de verificação, você pode extrair algumas informações dela.No meu último trabalho, criei um modelo com os cabeçalhos de seção e ajustei-o a partir daí.

Quanto às especificações funcionais, o importante é definir todas as interfaces:

  1. UI (modelos de tela)
  2. Interfaces de software (plug-ins, etc.)
  3. Interfaces de hardware (se apropriado)
  4. Interfaces de comunicação (serviços, e-mail, mensagens, etc.)

Também deve haver uma seção para regras de negócios, coisas que são importantes funcionalmente e que não são abordadas em nenhuma definição de interface.

Se você quiser comprar um livro, Requisitos de software por Karl Wiegers tem modelos para alguns documentos como apêndice.Infelizmente, estou no trabalho e esse livro específico está em casa.Se alguém tiver em mãos, poderá confirmar isso.

Acontece que gosto deste, entre outros: Conjunto pronto.

Ele vende uma versão profissional também.

Este é o melhor que encontrei: http://www.jiludwig.com/templates/FRDTemplate.doc

Comece de forma simples e trabalhe a partir daí.Como esta é sua primeira experiência trabalhando com isso, use um documento do Word com marcadores.Escreva, releia e forneça detalhes suficientes para que faça sentido.Para especificações técnicas, você pode querer orientar o desenvolvedor em direção a uma solução, mas para especificações funcionais o “como” deve estar completamente ausente.

Eu sugeriria dar uma olhada no modelo Volere de Roberston aqui.Eles fazem parte da Atlantic Systems Guild, junto com pessoas como Tom DeMarco e Timothy Lister, famosos pela "Peopleware".

Como o modelo é protegido por direitos autorais, não vou reproduzi-lo aqui, mas darei alguns dos principais cabeçalhos:

  1. O Objetivo do Projeto
  2. As partes interessadas
  3. Restrições obrigatórias
  4. Convenções e terminologia de nomenclatura
  5. Fatos e suposições relevantes
  6. O escopo do trabalho
  7. Modelo de dados empresariais e dicionário de dados
  8. O escopo do produto
  9. Requisitos funcionais
  10. Olhe e sente requisitos ...

Existem muitos mais, mas isso deve lhe dar uma ideia.A parte mais interessante do modelo é o shell de requisitos que lista os requisitos funcionais em uma espécie de cartão de sinalização.Novamente protegido por direitos autorais, mas verdadeiramente valioso.

Olhar aqui no capítulo 9.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top