Plantilla: Historia de Usuario A continuación presentamos la plantilla de HISTORIAS DE USUARIO, usada en nuestro proceso de ingeniería de software para identificar los requerimientos. Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema. Permite primordialmente identificar: •Como <Rol o Usuario> •Quiero <algún objetivo> •Para que <motivo> •Criterios de aceptación <validaciones> #XX Como <<rol>> quiero <<funcionalidad>> para poder <<beneficio>> CRITERIOS DE ACEPTACIÓN 1. <<Título escenario>> En caso que <<contexto>> y adicionalmente <<contexto>>, cuando <<evento>>, el sistema <<resultado / comportamiento esperado>> 2. <<Título escenario>> En caso que <<contexto>> y adicionalmente <<contexto>>, cuando <<evento>>, el sistema <<resultado / comportamiento esperado>> 3. <<Título escenario>> En caso que <<contexto>> y adicionalmente <<contexto>>, cuando <<evento>>, el sistema <<resultado / comportamiento esperado>> 4. <<Título escenario>> En caso que <<contexto>> y adicionalmente <<contexto>>, cuando <<evento>>, el sistema <<resultado / comportamiento esperado>> EJEMPLO #01 Como <<medico>> quiero <<generar una historia clínica>> para <<registrar información del paciente >> COMENTARIO: Para generar la historia clínica se deben seleccionar los datos del paciente y su historial de salud. CRITERIOS DE ACEPTACIÓN 1. 2. <<Existencia>> <<Actualización>> En caso que <<el paciente no tenga historia clínica en el sistema>>, cuando <<se intente generar una historia clínica >>, el sistema <<no debe dejar y debe mostrar un mensaje informativo>> En caso que <<el paciente tenga historia clínica >> cuando <<se guarde la historia clínica>>, el sistema <<debe informar y permitir almacenar y actualizar la historia clínica>> #02 Como <<usuario>> quiero <<registrarme como paciente>> para <<agendar una o varias citas médicas >> COMENTARIO: Para agendar una o varias citas el usuario debe estar registrado como paciente. CRITERIOS DE ACEPTACIÓN 1. 2. 3. <<Existencia>> En caso que <<el usuario no esté registrado en el sistema>>, cuando <<se intente generar una cita >>, el sistema << impide realizar esta acción y debe mostrar un mensaje informativo>> <<Existencia>> En caso que <<el usuario este registrado >> cuando <<se intente generar una cita >>, el sistema <<debe informar y permitir agendar la cita médica >> <<Actualización> En caso que <<el usuario modifique algún dato>>, cuando <<se intente guardar la modificaciones>>, el sistema <<debe informar y permitir la actualización de los datos>> #01 Como <<administrador>> quiero <<registrar clientes>> para <<control de vehículo>> COMENTARIO: Para generar la historia clínica se deben seleccionar los datos del paciente y su historial de salud. CRITERIOS DE ACEPTACIÓN 1. 2. 3. 4. <<Existencia>> En caso que <<el usuario no esté registrado en el sistema>>, cuando <<se intente solicitar el servicio >>, el sistema <<nodebe dejar y debe mostrar un mensaje informativo>> <<Actualización>> En caso que <<el usuario este registrado en el sistema >> cuando <<solicite el servicio>>, el sistema <<debe informar y permitir la solicitud del cliente>> <<Medios de Pago> En caso que <<el usuario no esté al día con su pago mensual>>, cuando <<se intente solicitar el servicio>>, el sistema <<no debe dejar y debe mostrar un mensaje informativo >> <<Retenciones>> En caso que <<la venta de origen a retenciones>> y adicionalmente <<se marque la factura con sugerencia de retenciones>>cuando <<se registren los artículos o servicios>>, el sistema <<debe sugerir las retenciones a aplicar>> #01 Como <<administrador>> quiero <<registrar clientes>> para <<control de vehículo>> COMENTARIO: Para generar la historia clínica se deben seleccionar los datos del paciente y su historial de salud. CRITERIOS DE ACEPTACIÓN 1. <<Existencia>> 2. <<Actualización>> 3. <<Medios de Pago> 4. <<Retenciones>> En caso que <<el usuario no esté al día con su pago mensual>>, cuando <<se intente solicitar el servicio>>, el sistema <<no debe dejar y debe mostrar un mensaje informativo >> En caso que <<el usuario este registrado en el sistema >> cuando <<solicite el servicio>>, el sistema <<debe informar y permitir la solicitud del cliente>> En caso que <<la venta de origen a retenciones>> y adicionalmente <<se marque la factura con sugerencia de retenciones>>cuando <<se registren los artículos o servicios>>, el sistema <<debe sugerir las retenciones a aplicar>>
