Prácticas recomendadas para el desarrollo de la solución
4. Recopilar los requisitos
Guía de prácticas recomendadas para el desarrollo de la solución
En este punto del desarrollo, debe tener un conocimiento experto de:
- El problema general y la solución
- Qué códigos de transacción o tablas de SAP se van a usar
- Qué hará o cómo funcionará cada script de Winshuttle Transaction/Query
- Quién participara en el flujo de trabajo y qué tareas realizará cada participante, tales como:
- Aprobar o rechazar
- Entrada de datos
- Cómo será la experiencia de usuario (UX).
- Qué aspecto tendrá el formulario (boceto) y qué guía de estilo lo regirá.
- La duración de cada tarea o proceso en el flujo de trabajo.
- El tipo de contenido que se le mostrará a cada usuario a medida que se vaya enrutando el formulario en el flujo de trabajo, entre lo que se incluyen:
- Vistas de formulario
- Qué contenido se puede editar y qué contenido será de solo lectura.
- Qué contenido se mostrará o se ocultará (basado en las vistas del formulario)
- Los casos de rechazo para cuando un elemento se rechaza, entre lo que se incluye:
- Cómo o cuándo terminar el proceso, si se rechaza
- Cómo o cuándo devolver una tarea al originador para que la corrija
- Cómo o cuándo reiniciar un proceso de aprobación y qué bucles utilizar hasta que algo se apruebe.
- Casos de escalación (si son necesarios)
- Notificaciones de correo electrónico
En una fase posterior del desarrollo, puede que sea más difícil integrar los cambios en los requisitos. Finalice y bloquee los requisitos para garantizarse un proceso de desarrollo rápido y correcto. Los cambios de requisitos que no sean determinantes deberían realizarse en el proceso de revisión, una vez la solución inicial se haya completado.
También será importante entender cada uno de los requisitos específicos para cada rol. Se acepta, del mismo modo, tener distintos documentos para los requisitos de los scripts, formularios y flujo de trabajo. Los desarrolladores de scripts, por ejemplo, tienen unos requisitos diferentes que los diseñadores.
El resultado final de esta fase debería ser un documento con requisitos completo y detallado.
El documento de requisitos debería ser lo suficientemente detallado como para proporcionar las especificaciones a nivel de campo y tarea. Lo ideal sería que incluyera los siguientes elementos:
- Una descripción de cada campo
- Cómo se etiquetará cada campo
- Qué lógica o cálculo se aplicará (en caso de que se aplique) cuando se introduzcan datos en cada campo
- El campo tipo para cada campo (desplegable, cuadro de texto...),
- Qué conexión de datos (en caso de que sea necesaria) necesita cada campo (SharePoint, SQL, etc.)
- Si el campo se muestra o está oculto
Cuanto más detallados sean los requisitos, el diseñador del formulario entenderá mejor cuáles son las necesidades exactas que hay que desarrollar tanto en el formulario como en el proceso de workflow. Si faltan elementos o no se especifican, el tiempo de desarrollo podrá extenderse.