Qual é a diferença entre requisitos e especificações? [fechadas]

122

Fui encarregado de desenvolver requisitos e especificações para um projeto que nosso grupo está iniciando.

Percebi que não sei a diferença; uma pesquisa no Google me confundiu mais - parece que algumas pessoas dizem que especificações são requisitos, mas em um nível mais baixo.

requirements specifications

Eu concordo com as respostas de alta votação, mas também acho que o termo especificação às vezes é usado como um termo mais genérico na indústria de software, referente a qualquer documento que descreva um sistema ou software. Como prova - google "especificação de requisitos". Quando usado dessa maneira, significa um documento que especifica algo - ou seja: especifica os requisitos para um software. Não vou julgar se esse é o uso correto da palavra ou não, só queria salientar que a especificação nem sempre significa a mesma coisa para todos.

— Shane Wealti

1

Sim, é por isso que as pessoas devem dizer "Requisitos comerciais" e "Especificação de design" / "Especificação técnica" ou algo assim. As palavras sozinhas são bastante vagas.

— user606723

Pense assim (de forma grosseira): Requisitos = documentos e especificações de requisitos = caso de uso / documentos de design

— PhD

4

Por que você não pergunta para a (s) pessoa (s) para quem está fazendo isso? Somente eles podem responder ao que é necessário no seu caso específico .

— 23411 Jaap

Este artigo oferece uma resposta completa: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

A resposta certa é que os requisitos são o que seu programa deve fazer, as especificações são como você planeja fazê-lo.

Outra maneira de analisar é que os requisitos representam o aplicativo da perspectiva do usuário ou do negócio como um todo. A especificação representa o aplicativo da perspectiva da equipe técnica. Especificações e requisitos comunicam aproximadamente as mesmas informações, mas a dois públicos completamente diferentes.

— Bryan Oakley
fonte

4

O quê / como a mordida de som é certa, mais ou menos; mas confuso, porque você também pode considerar a especificação de um programa como descrevendo o que ele deve fazer e o design como ele deve fazê-lo. Outro é o declarativo pl (como o prólogo e o SQL), no qual você declara o que não o como . Uma resolução é que eles são hierárquicos de abstrações, com os pais informando o que e os filhos informando como (fora vs dentro). Eu prefiro muito mais o seu segundo ponto de vista, que é parecido com "o que é para " versus "o que é ", isto é benefício recurso vs..

— 13ren

Em geral, eu concordo com você, mas é apenas outra opinião e não a resposta correta. Por exemplo, dê uma olhada na página Wiki de Requisitos ( en.wikipedia.org/wiki/Requirement ). Existem requisitos não funcionais, que por definição são para a equipe técnica. Ou requisitos de arquitetura e restrições, novamente técnicos, mas ainda assim eles não os chamam de 'especificações'. Eu acho que não há resposta correta e sempre será 'embaçada' de empresa para empresa e desenvolvedor para desenvolvedor.

— Jeach 29/11

1

Dê uma olhada na resposta 'Adam Wuerl' abaixo, acho que essa é a afirmação mais precisa da pergunta postada.

— Jeach 29/11

1

@Each: "abaixo" [sic] é relativo. Pode estar abaixo deste post neste momento, mas pode se mover acima, dificultando a compreensão do seu comentário #

— Bryan Oakley

1

Outra perspectiva. A Wikipedia define especificações como um "conjunto de requisitos". Isso significa que uma especificação pode ser apenas 1 requisito, s: = {r1}. Parece mais que "requisitos" coloquiais são requisitos de "alto nível", enquanto "especificações técnicas" são requisitos de baixo nível, uma coisa de LOD.

— Lance Pollard

38

Os requisitos documentam o que é necessário - eles não devem especificar o como, mas o que.

As especificações documentam como atingir os requisitos - elas devem especificar o como.

Em muitos lugares, esses documentos não são separados e são usados de forma intercambiável.

— Oded
fonte

2

Na minha empresa, normalmente usamos os termos "especificação de requisitos" para o quê (você especifica, anote os detalhes, o que você quer) e "especificação de design" para o como (você especifica, anota os detalhes, como você planejar implementá-lo).

— Giorgio

16

Sou engenheiro de sistemas no campo aeroespacial, onde os dois termos são usados extensivamente. A distinção é clara e não é tão complexa quanto os outros.

Uma especificação é um documento que especifica um sistema ou produto, por exemplo, uma especificação de desenvolvimento de item principal para um F-14. Existem muitas seções / conteúdo em uma especificação: requisitos, definições, documentos de referência, glossário, informações de verificação etc.

Um requisito é uma declaração única de algo que o produto ou sistema deve fazer. Uma especificação pode ter centenas de requisitos. A metodologia da velha escola diz que a declaração de requisitos deve usar a palavra "deve" para separar requisitos de declarações de fatos ou definições. (Não tenho certeza se os garotos ágeis, novos e fanáticos, mantêm tudo isso ou não; a meticulosidade tem seu uso, mas às vezes é um pouco exigente).

Portanto, uma especificação é um documento cheio de requisitos, além de outras informações de suporte e auxiliares.

— Adam Wuerl
fonte

4

Como eu disse em outro comentário, é muito embaçado para todos e provavelmente sempre será. Mas com base em minha própria pesquisa MUITO extensa sobre esse assunto exato, eu diria que sua resposta é a mais precisa para minhas próprias descobertas / conclusões.

— Jeach 29/11

2

Sempre útil para obter informações reais de um engenheiro. Obrigado!

— precisa saber é

Como alternativa, uma Especificação pode ter 0 requisitos. Seu exemplo é realmente bom para uma disciplina de engenharia aeronáutica muito específica. Não tenho certeza se é geralmente aplicável ao domínio de desenvolvimento / programação de software. Quando a maioria dos softwares é orientada por demandas de negócios, faz sentido começar com um Documento de Requisitos de Negócios detalhado antes de avaliar restrições técnicas e projetar uma solução. A Especificação Técnica seguiria o BRD, documentaria as restrições e forneceria uma abordagem detalhada e específica para atender aos requisitos de negócios no BRD.

— Bryan 'BJ' Hoffpauir Jr.

1

@ Bryan'BJ'Hoffpauir Tenho certeza de que há casos em que os documentos são rotulados como especificações e não têm requisitos, mas eu afirmaria aqueles que representam um uso indevido do termo. Uma especificação é um documento de requisitos - fim da história. É um termo de arte amplamente aceito em mais campos aeroespaciais e de defesa e é inatacável na engenharia de sistemas, que é a disciplina responsável pelos requisitos e pela verificação. Mesmo no caso em que você descreve o termo, o BRD é uma especificação, a especificação técnica também soa como uma, apenas com diferentes tipos de requisitos.

— Adam Wuerl

13

Requisitos:

Determine as necessidades ou condições a serem atendidas para um produto novo ou alterado, levando em consideração os requisitos possivelmente conflitantes das várias partes interessadas.

Especificações:

Eles fornecem uma idéia precisa do problema a ser resolvido, para que possam projetar o sistema com eficiência e estimar o custo das alternativas de design. Eles fornecem orientações aos testadores para verificação (qualificação) de cada requisito técnico.

A citação é de "Fundamentos de engenharia de sistemas ^* ".

Os requisitos são baseados nas necessidades das partes interessadas, as especificações são mais um documento técnico e detalhado. Eles são diferentes, mas falam da mesma coisa.

_{* Press Acquisition University Press, 2001. Versão em PDF do texto.}

— talabes
fonte

Eu acho que é importante que sua definição diga que as especificações definem o PROBLEMA. Dessa forma, uma especificação PROBLEM é um requisito. Uma especificação de SOLUÇÃO ou DESIGN faz parte do design.

— precisa saber é

6

Requisitos são a descrição dos usuários sobre o que o produto acabado, a seus olhos, deve fazer.

Especificação é a descrição técnica da solução em geral, cobrindo os requisitos e muito mais - por exemplo, custo, detalhes técnicos, problemas, etc.

Portanto, um dos pontos principais é que os Requisitos devem vir primeiro antes que uma Especificação possa ser escrita.

(Observe a terminologia - produto e solução - a mesma coisa, mas sob diferentes perspectivas ...)

— Arj
fonte

1

Eu trocaria os termos "produto" e "solução", porque uma solução geralmente é em termos do problema do cliente, enquanto um produto geralmente é em termos do vendedor (ou seja, o implementador técnico). Um contraste semelhante é o benefício / recurso, onde o benefício é em termos do cliente (de que serve isso para eles) e o recurso é em termos de implementação (o que realmente é , para que possamos obtê-lo).

— 13ren 29/11

1

Entendo o seu argumento, mas acho que qualquer um dos ângulos descreve adequadamente a situação. Entendi que um cliente compraria um produto - como você faz quando vai a uma loja. Um fornecedor de software estaria oferecendo sua solução para o problema subjacente. Se eu fosse comprar uma solução para o meu problema, provavelmente pensaria: "Preciso de um produto com xyz", não "Preciso de uma solução para o meu problema de abc". É apenas uma questão de preferência, eu acho.

— Arj

interessante. Posso ver os clientes "buscando um produto" quando há uma categoria de produto estabelecida. Mas eles procuram esse produto porque já descobriram que ele resolverá o problema deles - ou seja, eles procuram esse produto, não por si só, mas como uma solução. Também é verdade que um fornecedor comercializa seu produto como uma "solução" - mas isso é porque eles estão tentando se comunicar com os clientes (que buscam soluções para seus problemas) e criar algo que será desejado. Na verdade, a construção do produto (isto é, a coisa em si e suas características independente de por que eles são necessários)

— 13ren

Posso ver os clientes "buscando um produto", quando existe uma categoria de produto estabelecida - mas eles o procuram como solução para um problema / necessidade que eles têm. Os fornecedores comercializam seus produtos como "soluções" - porque estão se comunicando com os clientes (que têm problemas para exigir soluções). Ao criar o produto (a coisa em si e seus recursos, não o motivo pelo qual eles estão construindo). Um argumento é que um problema pode ter soluções muito diferentes - mas um produto é uma coisa específica.

— 13ren

[explicando o motivo de dois comentários]: os comentários do SO são tão dolorosos - pressionar "retornar" enviará o comentário, mesmo que seja uma área de texto com várias linhas. E se você demorar mais de 5 minutos para finalizá-lo depois disso, ele não aceitará a edição. Então você deve enviá-lo como um segundo comentário. Eu estava editando apenas para ajustá-lo no comprimento. suspiro . Da próxima vez, espalharei dois comentários em primeiro lugar ... [de qualquer forma, concordo que o ponto de vista - comprador / fornecedor - é a principal distinção. Estou incomodado com a sua terminologia, mas acho que aprofunda minha compreensão de tentar explicar o porquê.]

— 13ren 30/11/11

4

Requisito - o que o sistema ou subsistema deve (deve) fazer.

Especificação - Qual é o componente, subsistema ou sistema.

Isso é crítico no setor de fabricação de dispositivos médicos, pois você deve realizar a Verificação de acordo com seus requisitos (Entradas) para demonstrar que possui especificações válidas (Saídas). As armadilhas típicas desse setor são as empresas (1) que se esquecem de definir requisitos (porque não entendem a diferença entre requisito versus especificação); (2) Realize a verificação somente com as especificações e (3) não garanta que os Requisitos estejam sendo traduzidos com precisão nas especificações de submontagem e componentes.

Depois que tudo estiver pronto, você precisará validar os requisitos do usuário para o produto.

— Paul Bacchus
fonte

3

Talvez a confusão seja que ouvi as especificações se referirem aos documentos de especificação de requisitos de negócios ou documentos SRS (especificação de requisitos de software) IEEE padrão.

Exemplo de modelo SRS padrão IEEE

Também ouvi o termo especificações referir-se mais informalmente às Especificações Técnicas, que explicam as decisões de projeto e um plano de implementação.

EDIT: Acabei de perceber que o link está incorreto ... Em breve, postarei um link correto.

— maple_shaft
fonte

1

Bom ponto sobre o termo SRS!

— LeWoody 5/06

2

O link agora está completamente quebrado. Não sei ao certo o que apontou nem para qual material deve apontar.

3

Uma especificação é um requisito que passou na viabilidade e está pronto para ser implementado. É um requisito que evoluiu para a fase de design.

Em outras palavras:

Um requisito é o comportamento (ou não-comportamento) "conforme planejado" ou "conforme desejado"
Uma especificação é o comportamento (ou não-comportamento) "a ser construído" ou "como construído"

Exemplo:

requisito: 1. o usuário pressiona o botão OK 2. o sistema imprime a fatura
especificação: 1. o usuário pressiona o botão OK 2. o sistema imprime a fatura

Como você pode ver, o conteúdo de ambos pode ser o mesmo. A diferença é que o requisito é um artefato de análise. A especificação é um artefato de design.

Em uma documentação final construída, você normalmente encontrará a palavra "especificação", em vez de "requisito", pois os requisitos foram convertidos em especificações.

Observação: o exemplo acima contém elementos de design, devido a restrições de design.

— fox.bailey
fonte

0

Requisitos são o que o aplicativo FAZ

As especificações são como o aplicativo faz o que faz.

Eles devem ser ortogonais!

Os gerentes de produto escrevem os requisitos, os engenheiros-chefe escrevem as especificações.

— jayunit100
fonte

2

Não tenho certeza de que sejam completamente ortogonais, pelo menos na prática. Infelizmente, há muito cinza.

— LeWoody

Eles ficam cinzas apenas se você deixar de lado os modificadores - Requisitos de Negócios, Requisitos Funcionais, Requisitos Não Funcionais se referem a um recurso do sistema (o que ele faz). As especificações técnicas são ortogonais aos requisitos de negócios (o COMO o faz).

— Bryan 'BJ' Hoffpauir Jr.

0

Uma maneira, talvez não a maneira correta, de ver:

Requisitos são coisas (recursos, recursos, comportamentos etc.) que agregam valor ao usuário. Não está preocupado com os internos; apenas as entradas e saídas da caixa (e talvez tamanho, forma e cor) são importantes aqui.

Especificações são coisas (recursos, recursos, comportamentos, etc.) que ativam esse valor para o usuário. Aqui as caixas internas são importantes porque, juntamente com as interfaces e características externas mencionadas acima, elas definem todo o sistema.

— berad
fonte

Esta é apenas a sua opinião ou você pode fazer o backup de alguma forma?

— Gnat

2

@gnat, eu pensei que isso foi abordado na linha de abertura? Claro, isso é da experiência e não estou reivindicando mais nada - pelo que eu entendo, essa é uma pergunta um tanto subjetiva em um fórum bastante subjetivo, e este post sugere que as perguntas devem ser o mais objetivas possível, mas faz pouca menção às respostas . Mas eu tenho um pelo meu nome e você tem muito mais por isso estou aberto a ser educado :-)

— berad

0

Na minha pesquisa, encontrei Especificações para serem usadas em patentes e Construção de Casas (como parte de um contrato).

A definição de um requisito do Webster's Unabridged Dictionary (3rd New Int'l Ed.) É:

a) algo que é desejado ou necessário: Necessidade b) algo solicitado ou exigido: uma condição necessária ou essencial: uma qualidade, curso ou tipo de treinamento necessário

Eu acho que o acima mostra que eles são claramente diferentes. Eu acho que você poderia chamar os requisitos de nível inferior das especificações, mas acho que é uma perversão do termo imho de requisitos.

— LeWoody
fonte

0

Em uma empresa anterior que criou produtos comerciais, tivemos a seguinte distinção:

Requisitos são o que o sistema deve fazer. Eles podem ser de nível inferior, requisitos detalhados e podem ser funcionais ou não funcionais.

As especificações são aquelas que o sistema construído realmente faz. Por exemplo, você pode ter um requisito que declara que o sistema deve ter um comportamento X a –10 ° C. A especificação real do sistema pode ser que o sistema faça X a –5 ° C; isso estaria na planilha enviada aos clientes em potencial quando eles desejassem comprar o sistema.

NB: neste caso, a especificação não é igual ao requisito.

— RoyD
fonte

-1

Pense, você vai construir um edifício alto em um terreno.

Agora você precisa considerar os Requisitos antes de começar, como:

Engenheiro de Arquitetura ou Design
Engenheiro de Teste de Solo
Equipe de teste de pressão do vento
Demolidor
Escavador
Poder de homem
Abastecimento de água
Trabalhadores vivendo / área de descanso
Fundo suficiente
Gerenciamento de Projetos
Gestão da Qualidade
Segurança e Controle de Segurança

Etc.

Agora, o conteúdo acima faz parte dos Requisitos para construir um edifício alto. Da equipe acima, você obtém o resultado técnico, que eles mantêm como parte da profissão.

É exatamente isso que está acontecendo na indústria de software, um grupo de profissionais envolvidos para fornecer conhecimento para criar as especificações técnicas, como alguém que trabalha com design de interface do usuário, design de OO, design de banco de dados, design gráfico, design de caso de teste, codificação e integração , equipe de implantação etc.

O parágrafo acima fará parte do manual, que você pode chamar de Especificações Técnicas.

— Mohammed Hoq
fonte

1

Eu acho que você está confundindo requisitos com recursos ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston