Las reglas de negocio de integración de historias de los usuarios

Question

tengo un conjunto de historias de los usuarios y tengo un conjunto de reglas de negocio (principalmente leyes vinculantes mis requisitos para ser compatible). En ágil SDLC No estoy seguro de donde se unen estas "reglas" a mis historias de usuario.

Por ejemplo, una historia de usuario como:

  

Como médico Quiero añadir la información del paciente con el fin de crear un nuevo archivo de paciente.

Y una regla como:

  

La siguiente información se debe introducir en el registro de cada paciente:     (un paciente:    (I) el nombre y el nombre dado;    dirección (ii);    (Iii) la fecha de nacimiento; y    (Iv) el sexo;

Estos dos claramente se unen, pero ¿cómo les puedo vincular? Como las definiciones de aceptación del ensayo en mi historia de usuario? Otra historia de usuario?

Answer 1

Hay algunas maneras diferentes que he visto esta manejado:

1. Un artefacto se crea para mantener la regla de negocio y se almacena en algún repositorio central de toda la normativa por lo que este es conocida en todo el equipo de desarrollo y se mantiene un almacén de conocimientos. Esto puede poner feo ya que puede haber cientos de reglas dentro de pocos años de construcción de una solicitud.

2. Las reglas se puede poner en tarjetas separadas dentro de la historia de usuario. Por lo tanto, mientras que la historia de usuario es que una línea, puede haber 6-8 tarjetas que conforman todas las tareas para las que la historia para ser completado. Por ejemplo, tiene que haber una nueva forma creada paciente, la validación del formulario, etc. Por lo tanto, no es difícil ver este cultivo hasta abajo de la línea en una tarjeta como una manera de seguir el requisito de esa manera. Esta es la forma más natural a mi cuenta, sin embargo esto no es donde la lista específica va a ser 100% anotado ya sea como la tarjeta podría ser "aseguran algunos campos del formulario son obligatorios."

3. No hay una relación explícita, sino más bien la regla es algo para control de calidad o una licenciatura de nota para el usuario verificar que la forma hace cumplir esta regla. Esto es similar a uno, pero la pregunta es ¿cuál es la responsabilidad del desarrollador en este. En este caso, se trata de algo de control de calidad para realizar un seguimiento en lugar de los desarrolladores posiblemente.

La historia de usuario tiene la intención de iniciar una discusión, no puede ser una lista exhaustiva de los requisitos. La regla es algo que debe llegar cuando los desarrolladores discute con el usuario ¿Qué se necesita para crear un nuevo archivo de paciente a mi mente.

---

Me gusta la idea de aferrarse a las tarjetas para un par de carreras después se realizó la historia, pero sí veo el punto de que las tarjetas en última instancia, serán destruidos. Al mismo tiempo, debe haber alguna parte de código que implementa las reglas en su área apropiada. Para utilizar el ejemplo que has publicado, puede ser que en algunos lugares de la lista de campos obligatorios se notaría, ya que es la capa de interfaz de usuario que tiene que mostrar los campos y, probablemente, un mensaje de error, pero también debe haber una cierta capa de lógica de negocios que tiene esta lógica de ver que algunos campos se completaron específicamente antes de intentar crear un nuevo archivo de paciente. El sistema está construyendo también albergará las reglas de una forma u otra, también.

Answer 2

Como criterios de aceptación. Después de todo se trata de normas que se pueden ejecutar como pruebas. Definitivamente no nuevas historias, eso sería incorrecto ya que no hay meta entregable.