Documentar los requisitos funcionales y los artefactos

Completado

Conforme vaya recopilando requisitos, se diferenciarán normalmente entre funcionales o no funcionales. Los requisitos funcionales describen lo que debe hacer la solución o sus comportamientos, y los requisitos no funcionales normalmente se usan para describir aspectos de la solución que no son comportamientos, como los requisitos de rendimiento. En esta lección, trataremos algunos aspectos a tener en cuenta para los requisitos funcionales.

Cada requisito funcional debe capturar claramente el quién, el qué y el por qué del requisito. Si el requisito es demasiado grande, debe separarse en partes más pequeñas.

Requisitos funcionales

Los siguientes escenarios son algunos ejemplos sencillos de requisitos funcionales:

• Como usuario de ventas, necesito poder cerrar una oportunidad como perdida y capturar por qué se perdió, para poder mejorar nuestras tácticas de venta en el futuro.
• Como jefe de ventas, necesito poder aprobar un descuento en una oferta para poder reducir el precio total y ofrecer un descuento al cliente.
• Como contable en plantilla, quiero que se me impida cerrar un lote que tenga elementos pendientes, para no tener que volver a abrirlo más tarde.

Estos ejemplos comunican el quién, el qué y el por qué.

Los siguientes son algunos ejemplos de requisitos mal redactados:

• Las oportunidades se pueden ganar o perder.
• El precio debe reflejar los descuentos.
• En la lista de elementos de lote, al hacer clic en el botón Cerrar lote, que es el tercer botón por la izquierda, se debe cerrar el lote si no existen elementos que impidan que ocurra.

Cuando se recopilan requisitos de cualquier variedad, es muy útil crear un mapa hacia el proceso o el recorrido del cliente, y no tan solo una lista de características y funciones. Cree una historia para un usuario y cómo utilizará el sistema que está diseñando. Puede garabatear en una pizarra, usar una herramienta para crear un diagrama del proceso, lo que sea mejor para el equipo en la fase de planificación en la que se encuentra. Su equipo diseccionará más tarde las piezas en elementos accionables más pequeños.

Criterios de aceptación

Es importante tener una comprensión clara de cómo se considera satisfecho un requisito. A menudo, documentar este requisito ayudará a determinar si el requisito está suficientemente detallado y es del tamaño correcto. Esta documentación también es útil para los equipos de prueba, para evaluar la implementación del requisito. Finalmente, debe revisarse con la parte interesada para garantizar que sea precisa, ya que puede usarse para ayudar a evitar el desplazamiento del ámbito. Es importante buscar criterios de aceptación que posiblemente no se puedan cumplir y negociar para llegar a un compromiso que sea alcanzable.

Captura de excepciones

Por lo general, un requisito sencillo, como cerrar una transacción, puede tener una ruta directa y tan solo algunas rutas de excepción. Es importante buscar e identificar estas excepciones al capturar el buen camino. A medida que avance en el diseño, no le interesará centrarse en las excepciones. Deben manejarse como tales pero, si no sabe que existen, tendrá que volver a trabajar en el diseño más adelante. También es bueno recordar capturar con qué frecuencia se produce la excepción, ya que algunas excepciones se manejan mejor por procedimiento o proceso que mediante personalización del software.

Evitar el desplazamiento del ámbito

Dejar todos los proyectos sin comprobar agregaría ámbito a partir de lo previsto y presupuestado. El proceso de gobernanza del proyecto debe usarse para evaluar cómo controlarlos una vez identificados. A menudo, los que se aceptan para su inclusión pueden dar lugar a un pedido de cambio, dependiendo de la estructura contractual del proyecto. Simplemente ignorar el hecho de que el ámbito está aumentando puede provocar fácilmente que el proyecto falle.

Internacionalización

Microsoft Power Platform ofrece a los fabricantes muchas opciones para internacionalizar las aplicaciones. Las aplicaciones basadas en modelos y las aplicaciones de portal vienen con opciones de internacionalización que incluyen paquetes de idiomas y multidivisa. Documentar con precisión estos requisitos es esencial para la adopción por parte del usuario. La documentación de la internacionalización debe comenzar con los requisitos e incluirse en los planes de prueba de garantía de calidad, las pruebas de adopción de usuarios y la documentación del sistema. Asegúrese de seguir las prácticas recomendadas que se enumeran aquí para documentar también los requisitos procesables y comprobables para las necesidades de internacionalización.

Artefactos de soluciones

Se considera una buena práctica dar nombres lógicos a los componentes de la solución y, a medida que vaya preparando la documentación de dichos nombres lógicos, sin duda verá los resultados. La documentación de cada proyecto de estos elementos puede ser un poco diferente entre sí.

El objetivo de esta documentación debe ser garantizar la continuidad constante de las soluciones, a medida que evolucionan con el tiempo, así como mantener informado al equipo del proyecto. Esto es particularmente útil al participar en un equipo de creadores donde cada miembro del equipo está trabajando en un conjunto diferente de funcionalidades. Documentar lo importante será mucho más fácil si hay nombres predecibles y documentación coherente de nombres y comportamientos esperados.

Los elementos de planificación del proyecto, como las historias de usuarios o los elementos de la lista de trabajos pendientes, pueden ser buenos recursos para ayudar a comenzar con su documentación. Por muy tentador que sea esperar a preparar esta documentación hasta la finalización del proyecto, será un recurso posterior más útil si se completa al menos en cada hito del proyecto. Podrá notar y corregir incoherencias y errores antes de que se conviertan en problemas mayores.

Al documentar tablas (ya sea en una aplicación basada en modelos o con un origen de datos Dataverse), plantéese incluir una descripción de las tablas, por ejemplo, su uso previsto. Incluya las columnas de cada tabla y su tipo de datos y descripción. Documente las relaciones entre las tablas y los comportamientos definidos, como los comportamientos de eliminación de filas. También se deben incluir todas las consideraciones para los roles de seguridad y la seguridad en el nivel de columna. Vistas de documentos y sus consultas; formularios y sus públicos/usos objetivo; informes y paneles.

La automatización incluye los flujos de proceso de negocio, flujos de Power Automate, reglas de negocio y flujos de trabajo clásicos. No solo debe documentar cada una de estas automatizaciones diferentes, sino que también debe documentar cómo funcionan juntas. Los conectores utilizados y sus requisitos también se pueden documentar aquí.

Los componentes de las aplicaciones de lienzo a documentar incluyen pantallas específicas y su navegación, orígenes de datos utilizados, fórmulas y desencadenadores para la automatización. Los portales de Power Apps tienen necesidades de documentación similares a las de las aplicaciones de lienzo, pero también incluirán la diferenciación entre usuarios autenticados y usuarios anónimos.

Al documentar Power Virtual Agents, incluya el flujo de conversación en el nivel de tema, los orígenes de datos específicos y planes de escalación.

Además de los detalles técnicos específicos, puede resultarle útil escribir descripciones del recorrido del usuario. Esto alcanza más allá de "El usuario hace clic aquí", y más de la totalidad de la experiencia esperada. Piense en ello como la historia de la interacción diaria de ese usuario con la solución. Teniendo en cuenta la audiencia de esta documentación, tenga en cuenta consideraciones como la accesibilidad en la documentación y el ofrecimiento tanto de palabras como de explicaciones gráficas. Esta documentación podría ser útil para incorporar nuevos miembros del equipo, crear criterios de aceptación del usuario y entregar el proyecto al cliente una vez finalizado.

Documentar datos para migración e integración

Raramente se comienza un proyecto sin consideraciones heredadas. Los usuarios tienen aplicaciones ineficientes que usan muchísimos datos comerciales que ya conocen. Dependiendo de las circunstancias exactas, puede conectarse con los datos o migrarlos. Cualquiera de estos caminos requiere planificación y documentación.

Independientemente de la migración o la integración, la calidad de los datos es muy importante. ¿Son precisos los datos? ¿Hay datos antiguos que ya no son relevantes? ¿Hay duplicados a mitigar? ¿Podemos eliminar los duplicados antes de la migración?

Crear una lista de comprobación (y seguirla) será útil para minimizar los efectos de incorporar los datos antiguos a la nueva solución.

Documentar los orígenes de datos: identifique el origen de datos y las conexiones utilizados. Identifique la calidad de los datos de origen. Identifique las columnas que se están migrando, teniendo en cuenta que no todos los datos de origen irán al nuevo sistema.

Tipos de datos de documentos: compare los datos de origen con el esquema de destino. Identifique posibles problemas de transformación antes de comenzar el movimiento de los datos.

Asignación de datos de documentos: complete una revisión columna por columna de los datos que llegan al sistema y confirme que estén asignados correctamente. Concilie las diferencias en los metadatos de las columnas de datos de origen y de destino.

Manejo de errores de documentos: haga un plan para solucionar los errores de importación o integración.

Acomodarse a excepciones: no todo será una asignación exacta de uno a uno de los datos desde el origen al nuevo entorno. Identifique estas excepciones y prepare un plan.

Documentar la evaluación continua de calidad de los datos: revise, informe y repare la calidad de los datos.