Estou tentando entender um pouco melhor a diferença, pois parece que elas são a mesma coisa.
Trabalho em projetos sem o uso dos requisitos e tudo é um critério de aceitação, e em projetos que possuem ambos.
Estou tentando entender um pouco melhor a diferença, pois parece que elas são a mesma coisa.
Trabalho em projetos sem o uso dos requisitos e tudo é um critério de aceitação, e em projetos que possuem ambos.
Respostas:
O critério de aceitação define quando o aplicativo é concluído. Ou, em outras palavras, quando você pode enviá-lo. Inclui uma lista de requisitos que ele has toatende. Isso significa que alguns requisitos (geralmente requisitos "bons de ter") podem cair e ser implementados na próxima versão.
Para expandi-lo ainda mais (extraído daqui ):
A Microsoft Press define Critérios de aceitação como "Condições que um produto de software deve satisfazer para ser aceito por um usuário, cliente ou outra parte interessada". O Google os define como "padrões ou requisitos pré-estabelecidos que um produto ou projeto deve atender".
e
Critérios de aceitação são um conjunto de declarações, cada uma com um resultado claro de aprovação / reprovação, que especificam requisitos funcionais (por exemplo, funcionalidade comercializável mínima) e não funcionais (por exemplo, qualidade mínima) aplicáveis no estágio atual da integração do projeto. Esses requisitos representam "condições de satisfação". Não há aceitação parcial: um critério é atendido ou não.
Um requisito descreve uma certa funcionalidade do aplicativo.
Ou, como bem declarado no wiki :
um requisito é uma necessidade física e funcional documentada singular que um projeto, produto ou processo específico deve poder executar.
Qual é a diferença entre os critérios de aceitação e os requisitos de inscrição?
Com as definições acima, a diferença é bastante clara.
Os requisitos são o que o cliente solicitou.
Os Critérios de Aceitação, geralmente expressos como testes, são usados para ilustrar Requisitos e para indicar, quando os testes passam, que os Requisitos foram atendidos.
Muitas vezes é uma questão de tempo
Os requisitos estão adiantados. Os critérios de aceitação estão no ponto de entrega do software.
Isto é como os outros responderam ...
Há um problema mais profundo e talvez você o esteja vendo:
Em um mundo "ideal", isso seria apenas o mesmo. No entanto, no mundo real, muita coisa acontece entre esses dois eventos, geralmente incluindo alguns dos seguintes:
É freqüentemente uma questão de 'nível de detalhe', com os requisitos em um nível alto, por exemplo, "um módulo de processamento de reembolso" e os critérios de aceitação em um nível mais baixo e mais detalhado, como "um reembolso solicitado deve ser concluído dentro de 3 dias". dias e um aviso por e-mail ao cliente "
Os requisitos se enquadram na verificação que responde à pergunta:
O produto foi construído corretamente? (de baixo para cima, de acordo com os requisitos)
Os Critérios de Aceitação se enquadram na validação que responde à pergunta:
O produto correto foi construído? (de cima para baixo, como evidenciado pela aprovação nos testes de aceitação)
Os requisitos geralmente são conduzidos pelo cliente. Em um padrão de desenvolvimento em cascata, esta é a lista de resultados esperados da conclusão de um projeto. Em sua descrição mais básica, os requisitos nada mais são do que tarefas de um projeto.
Critérios de aceitação geralmente são conduzidos pelo relacionamento entre duas partes. Eles podem ser independentes dos requisitos e / ou relacionados aos requisitos. Isso não os torna a mesma coisa, mas apenas relacionados. Ao contrário dos critérios de aceitação de requisitos, não é uma lista de tarefas. É uma lista de condições que devem ser atendidas para que o contrato seja considerado concluído.
Algumas respostas declararam testes de unidade, orçamento e gerenciamento de projetos como exemplos, mas esses são apenas exemplos de condições impostas ao contrato como critério de aceitação .
É possível que um desenvolvedor não preencha nenhum dos requisitos e ainda atenda aos critérios de aceitação para concluir o projeto.
Por exemplo;
Requisito para atualizar o sistema de ponto de vendas com novas alterações na lei tributária. Os critérios de aceitação entre o desenvolvedor e o desenvolvedor dos estados clientes concordam em concluir 40 horas de trabalho para executar a atualização. Se o trabalho não for concluído nesse período, nenhuma atualização para o sistema será publicada, pois esse é o limite do orçamento do cliente.
O desenvolvedor entra em acordo e, após 40 horas de trabalho, ele relata que a alteração é significativa, resultando em mais de 40 horas para terminar. O cliente aceita esse resultado, paga ao desenvolvedor o salário e o contrato é concluído.