Escrevendo uma especificação de requisitos de software


15

Tenho algumas perguntas sobre como escrever uma especificação e elas são:

  1. Quando escrevemos uma especificação de software, no tópico "Definição de requisitos do usuário", precisamos especificar apenas as "Funções" e "Restrições"?

  2. "Interface do usuário" se enquadra em "funções" ou "restrições"?

  3. Quais são as principais áreas principais (requisitos) em que um software pode ser dividido (por exemplo, interface do usuário)?


Este artigo pode ser útil: 10 erros típicos em Specs
yegor256

Respostas:


16

Embora eu não seja um grande fã de reunir todos os requisitos em detalhes antecipadamente (como eles estão sujeitos a muitas mudanças ao longo de um projeto não trivial), se você estiver escrevendo documentos de requisitos, o modelo de especificação de requisitos Volere é um excelente guia .

Embora possa ser um exagero para alguns projetos, ele fornece uma ótima lista de verificação para pensar, mesmo que seja apenas para marcar mentalmente a lista de que você não precisa desse item para esse requisito.

Aqui está um link para mais informações sobre o modelo:

http://www.volere.co.uk/template.htm

O modelo em si (e o livro Dominar o processo de requisitos - que na verdade é um pouco mais barato que o modelo e contém o texto completo do modelo) contém muitas informações, exemplos e conselhos nas várias seções sobre o que deve acontecer em cada seção.

Aqui está um resumo das seções (citadas no link acima):

  1. O objetivo do projeto

  2. As partes interessadas

  3. Restrições obrigatórias

  4. Convenções e definições de nomenclatura

  5. Fatos e Premissas Relevantes

  6. O escopo do trabalho

  7. Modelo de Dados Corporativos e Dicionário de Dados

  8. O escopo do produto

  9. Requisitos funcionais e de dados

  10. Requisitos de aparência

  11. Requisitos de usabilidade e humanidade

  12. Requisitos de desempenho

  13. Requisitos operacionais e ambientais

  14. Requisitos de manutenção e suporte

  15. Requisitos de segurança

  16. Requisitos culturais e políticos

  17. Requerimentos legais

  18. Edições em aberto

  19. Soluções prontas para uso

  20. Novos problemas

  21. Tarefas

  22. Migração para o novo produto

  23. Riscos

  24. Custos

  25. Documentação e treinamento do usuário

  26. Sala de espera

  27. Ideias para soluções


10

Eu recomendo ler Joel no software. Não tenho certeza se ele responde a perguntas específicas, mas ele tem uma excelente visão geral do que significa escrever especificações funcionais :

A função mais importante de uma especificação é projetar o programa . Mesmo se você estiver trabalhando sozinho no código e escrever uma especificação exclusivamente para seu próprio benefício, o ato de escrevê-la - descrevendo como o programa funciona em mínimos detalhes - forçará você a realmente projetar o programa ...

... quando você projeta seu produto em uma linguagem humana, leva apenas alguns minutos para tentar pensar em várias possibilidades, revisar e melhorar seu design. Ninguém se sente mal quando exclui um parágrafo em um processador de texto. Mas quando você projeta seu produto em uma linguagem de programação, leva semanas para fazer projetos iterativos. O que é pior: um programador que passa apenas duas semanas escrevendo algum código ficará bastante ligado a esse código, não importa o quão errado ele seja ...

... Ao escrever uma especificação, você só precisa comunicar como o programa deve funcionar uma vez . Todos na equipe podem apenas ler as especificações. O pessoal do controle de qualidade lê o documento para saber como o programa deve funcionar e saber o que testar. O pessoal de marketing o usa para escrever seus vagos white papers de vaporware para vomitar no site sobre produtos que ainda não foram criados. O pessoal do desenvolvimento de negócios o interpretou mal para gerar fantasias estranhas sobre como o produto curará a calvície, verrugas e outras coisas, mas atrai investidores, então tudo bem. Os desenvolvedores leem para saberem o código a escrever. Os clientes leem para garantir que os desenvolvedores estejam criando um produto pelo qual desejam pagar. Os escritores técnicos leem e escrevem um bom manual ...

Quando você não tem uma especificação, toda essa comunicação ainda acontece, porque precisa , mas acontece ad hoc . O pessoal do controle de qualidade brinca com o programa à toa e não, e quando algo parece estranho, eles interrompem os programadores mais uma vez para fazer outra pergunta estúpida sobre como a coisa deve funcionar ...

sem uma especificação detalhada, é impossível fazer um cronograma ... Em muitas organizações de programação, toda vez que há um debate sobre design, ninguém consegue tomar uma decisão, geralmente por razões políticas. Portanto, os programadores trabalham apenas em coisas incontroversas. À medida que o tempo passa, todas as decisões difíceis são levadas ao fim ... Escrever uma especificação é uma ótima maneira de definir todas aquelas decisões irritantes de design, grandes e pequenas, que ficam encobertas se você não tiver uma especificação. ..


@gnat Eu não acho que a citação do artigo é necessária. Se você deseja destacar sua escolha de trechos, sugiro que você publique sua própria resposta à pergunta.
Jonathan Swinney

considere fazer uma leitura para Sua resposta está em outro castelo: quando uma resposta não é uma resposta? "deixe-me ser claro: esse tipo de resposta não é uma resposta . Se você vir isso, sinalize-o. Moderadores, se você vir sinalizá-lo, exclua-o "
gnat

1
Se você não concordar com os trechos citados, fique à vontade para editá-los. No entanto, ter uma resposta que é apenas um link não é considerada uma boa resposta e está sujeita a exclusão de acordo com nossas políticas de qualidade. Uma postagem que se refira a um recurso ou referência externa deve fornecer informações suficientes para continuar agregando valor se o link não estiver acessível por qualquer motivo.
Thomas Owens

6

Quando escrevemos uma especificação de software, no tópico "Definição de requisitos do usuário", precisamos especificar apenas as "Funções" e "Restrições"?

Um requisito é uma combinação de duas coisas ...

  1. O que a coisa faz. Requisito funcional.
  2. Quão bem ele faz isso. Requisito não funcional ou "restrição"

"Interface do usuário" se enquadra em "funções" ou "restrições"?

Eu diria que "Interface do usuário" seria uma categoria de requisitos, como você identificou na sua última pergunta.

Quais são as principais áreas principais (requisitos) em que um software pode ser dividido (por exemplo, interface do usuário)?

Depende do software. Você pode agrupar requisitos com base em partes do sistema ou agrupá-los com base no caso de uso ou no requisito de negócios que as funções estão cumprindo.

É claro que tudo isso é secundário ao seu objetivo real, que é determinar uma descrição clara, inequívoca e testável do sistema de software.


4

O principal requisito para um requisito é que ele seja testável. Se você não conseguir descobrir como testar um requisito, é provável que ele não seja implementado da maneira que o escritor pretendia.

Eu nunca vi um documento de requisitos limitado apenas a Funções e restrições, mas posso ver algum valor em ter uma estrutura como esta - ele força o escritor a categorizar os requisitos em "coisas que o software precisa fazer" e "governa o o software precisa seguir. "

Eu acho que uma interface de usuário tem requisitos em ambas as categorias

Restrições:

  • "a tela de inicialização deve exibir dois botões:" Iniciar "e" Parar "
  • "A fonte de exibição não deve ser menor que 10 pontos."

Funções:

  • "Quando a Starttecla é pressionada, o software estabelece uma conexão TCP / IP ao WOPR "

Seus exemplos não são requisitos, são design. As especificidades de como o requisito deve ser cumprido são uma decisão de design, não um requisito. Assim, "dois botões" é uma decisão de design. Torna-se óbvio quando você percebe que existem muitas outras maneiras válidas de atingir o mesmo objetivo (Iniciar ou Parar alguma coisa). Assim, para torná-lo mais um requisito, você diria "A interface do usuário deve fornecer um meio para iniciar e parar algo". Mas eu iria além, porque usar uma interface do usuário também é uma decisão de design. Assim, para os requisitos do sistema seria "O sistema deve fornecer um meio para iniciar e parar alguma coisa"
Dunk
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.