El criterio de aceptación define cuándo finaliza la solicitud. O para decirlo de otra manera, cuando puedes enviarlo. Incluye una lista de requisitos que has tocumple. Esto significa que algunos requisitos (por lo general, requisitos "agradables de tener") pueden caerse e implementarse en la próxima versión.
Para expandirlo aún más (tomado de aquí ):
Microsoft Press define los Criterios de aceptación como "Condiciones que un producto de software debe cumplir para ser aceptado por un usuario, cliente u otra parte interesada". Google los define como "estándares o requisitos preestablecidos que un producto o proyecto debe cumplir".
y
Los criterios de aceptación son un conjunto de declaraciones, cada una con un claro resultado de aprobado / reprobado, que especifican requisitos funcionales (por ejemplo, funcionalidad mínima comercializable) y no funcionales (por ejemplo, calidad mínima) aplicables en la etapa actual de integración del proyecto. Estos requisitos representan "condiciones de satisfacción". No hay aceptación parcial: se cumple un criterio o no se cumple.
Un requisito describe una cierta funcionalidad de la aplicación.
O, como bien dijo la wiki :
Un requisito es una necesidad física y funcional documentada singular que un diseño, producto o proceso particular debe poder realizar.
¿Cuál es la diferencia entre los criterios de aceptación y los requisitos de la solicitud?
Con las definiciones anteriores, la diferencia es bastante clara.
Los requisitos son lo que se supone que debes hacer.
Los criterios de aceptación son las medidas acordadas para demostrar que las ha cumplido.
fuente
Los requisitos son lo que el cliente / cliente ha pedido.
Los criterios de aceptación, a menudo expresados como pruebas, se utilizan para ilustrar los requisitos y para indicar, cuando pasan las pruebas, que los requisitos se han cumplido.
fuente
A menudo es cuestión de tiempo
Los requisitos son por adelantado. Los criterios de aceptación se encuentran en el punto de entrega del software.
Esto es como otros han respondido ...
Sin embargo, hay un problema más profundo y quizás lo estés viendo:
En un mundo "ideal" estos simplemente coincidirían. Sin embargo, en el mundo real sucede mucho entre estos dos eventos, que a menudo incluyen algunos de los siguientes:
Con frecuencia es una cuestión de 'nivel de detalle', con los requisitos en un nivel alto, por ejemplo, "un módulo de procesamiento de reembolsos" y los criterios de aceptación en un nivel más bajo y más detallado como "un reembolso solicitado debe completarse dentro de 3 días y un aviso enviado por correo electrónico al cliente "
fuente
Los requisitos se encuentran bajo verificación, lo que responde a la pregunta:
Los criterios de aceptación se encuentran bajo validación, lo que responde a la pregunta:
fuente
Los requisitos a menudo son impulsados por el cliente. En un patrón de desarrollo en cascada, esta es la lista de resultados esperados de la finalización de un proyecto. En su descripción más básica, los requisitos no son más que una tarea pendiente para un proyecto.
Los criterios de aceptación a menudo son impulsados por la relación entre dos partes. Pueden ser independientes de los requisitos y / o estar relacionados con los requisitos. Eso no los hace lo mismo, sino solo relacionados. A diferencia de los requisitos, los criterios de aceptación no son una lista de tareas pendientes. Es una lista de condiciones que deben cumplirse para que el acuerdo se considere terminado.
Algunas respuestas han establecido pruebas unitarias, presupuestos y gestión de proyectos como ejemplos, pero esos son solo ejemplos de condiciones colocadas en el acuerdo como criterio de aceptación .
Es posible que un desarrollador no complete ninguno de los requisitos y aún así cumpla con los criterios de aceptación para finalizar el proyecto.
Por ejemplo;
Requisito de actualizar el sistema de punto de venta con nuevos cambios en la legislación fiscal. Los criterios de aceptación entre el desarrollador y el cliente declaran que el desarrollador acepta completar 40 horas de trabajo para realizar la actualización. Si el trabajo no se completa en ese tiempo, no se publicarán actualizaciones para el sistema, ya que este es el límite presupuestario de los clientes.
El desarrollador firma el acuerdo y, después de 40 horas de trabajo, informa que el cambio es significativo, lo que resulta en más de 40 horas para finalizar. El cliente acepta este resultado, le paga al desarrollador su salario y su acuerdo está terminado.
fuente