Escrevendo uma especificação de requisitos de software

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)?

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

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. ..

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.

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 "