PRO-DGT-009 Desarrollo de Requisitos Funcionales del Sistema

v 3.1 / TS, VER, VAL, PMC, RD, CM, PPQA, REQM

Propósito

Definir la forma de trabajo al momento de desarrollar un Requerimiento Funcional para incrementar el yield en la detección de defectos en la misma fase que son inyectados y alinear las decisiones tomadas en cada fase con los Requerimientos No Funcionales para garantizar que el sistema cumpla con las expectativas de calidad.

Notas Introductorias

Completar cada fase y documentar correctamente el trabajo realizado es importante para monitorear la trazabilidad de un requisito y disminuir la deuda técnica.

En el equipo de Zeitgeist, las inconsistencias las definimos como aquellos productos de trabajo (código, diseño, análisis) que no cumplan con las checklists correspondientes, ni con los productos anteriores en la fase de desarrollo, aquellos diseños de frontend que distingan demasiado de su wireframe, documentación fuera de lugar, tener los modelos o la matriz de trazabilidad desactualizados.

Involucrados

Team Members, Architecture Owner, Team Lead y Project Owner

Entradas

• Especificación de Requerimientos de Software (ERS)
• Wireframes diseñados en Figma
• Plan de Valor Ganado (PVG)
• Matriz de Trazabilidad de Requerimientos (RTM)

Salidas

• Funcionalidad implementada en el sistema en la rama develop del repositorio de GitHub
• Documentación de cada fase ejecutada en el PVG y la RTM

Descripción

Fase	Actividades	Responsables	Prácticas Asociadas del CMMI
Análisis	1. Revisar todos los Requisitos No Funcionales (RNF) previamente identificados en el ERS. Las decisiones de análisis deben estar alineadas con los RNF para garantizar que el sistema cumpla con las expectativas de calidad. 2. Revisar los criterios de aceptación del requisito a desarrollar en el ERS. En caso que este Requisito Funcional dependa de otro para su desarrollo, revisar el impedimento con el Team Member asignado al Requisito Funcional requerido. 3. Redefinir los criterios de aceptación de ser necesario para que describan la funcionalidad del requisito y los limitantes del mismo. 4. Diseñar las Pruebas de Integración del Front y las Pruebas del Sistema en Voz Alta. Para ello, revisar el Plan de Pruebas. 5. Revisar el Wireframe con el ID del RF (RF##) correspondiente al requisito en el Figma. En caso de que el Wireframe no se encuentre disponible aún, solicitar el apoyo del equipo de UX/UI. 6. Realizar actualizaciones al MER si es necesario. 7. Realizar actualizaciones al Modelo Relacional si es necesario. 8. Realizar actualizaciones al Diccionario de Datos si es necesario. 9. Revisar que el requisito funcional esté agregado como un item en el PVG así como que tenga su valor planeado, costo planeado y fecha planeada. 10. Incluir el ERS y el Wireframe de Figma en la Matriz de Trazabilidad de Requerimientos en la fase de Análisis. 11. Añadir todos los ítems de trabajo del proceso en la RTM 12. Al terminar, registrar el tiempo en el PVG en Análisis.	Team Member	TS SP 2.2 TS SP 2.3 RD SP 2.1 RD SP 2.2 RD SP 2.3 RD SP 3.1 VER SP 1.3 PMC SP 1.1 REQM SP 1.4
Verificación del Análisis	1. Verificar los criterios de aceptación y pruebas con la CHK-DGT-009 Checklist de Análisis. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el PVG en Análisis.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Validación del Análisis	1. Validar los criterios de aceptación y pruebas con las personas capacitadas; estás personas son los PO y Ex-POs debido a que conocen de cerca la necesidad del cliente y están o estuvieron en contacto directo con ellos. Para ello, utilizar la CHK-DGT-009 Checklist de Análisis. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el PVG en Análisis.	Team Member, PO	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.1 VAL SP 1.2 VAL SP 1.3 VAL SP 2.1 VAL SP 2.2 RD SP 3.3 RD SP 3.5 PMC SP 1.1 REQM SP 1.5
Diseño	1. Revisar todos los Requisitos No Funcionales (RNF) previamente identificados en el ERS. Las decisiones de diseño deben estar alineadas con los RNF para garantizar que el sistema cumpla con las expectativas de calidad. 2. Diseñar un diagrama de secuencia siguiendo el EST-BDT-002 Diagramas UML. 3. Subir el diagrama en la carpeta de Diagramas con el nombre RF##. 4. Agregar el enlace del diagrama diseñado en la Matriz de Trazabilidad de Requerimientos en la fase de Diseño. 5. Al terminar las tareas, registrar el tiempo en el PVG en Diseño. 6. Revisar que el requisito funcional a desarrollar cumpla con la definición de Ready	Team Member	TS SP 2.1 RD 2.2 RD 3.2 PMC SP 1.1 REQM SP 1.4
Verificación del Diseño	1. Verificar los criterios de aceptación y pruebas con la CHK-DGT-006 Checklist de Diseño. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el PVG en Diseño.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Validación del Diseño	1. Validar los diagramas diseñados con las personas capacitadas; estás personas son los AO y Ex-AOs debido a que conocen a detalle la arquitectura del proyecto, el stack tecnológico y están o estuvieron activos en la definición de los mismos. Para ello, utilizar la CHK-DGT-006 Checklist de Diseño. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 3. Al terminar, registrar el tiempo en el PVG en Diseño. 4. Actualizar el Status en la Matriz de Trazabilidad de Requerimientos como Ready.	Team Member, AO	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.1 VAL SP 1.2 VAL SP 1.3 VAL SP 2.1 VAL SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.4 REQM SP 1.5
Preparación del ambiente de Desarrollo	Revisar las siguientes guías para preparar el ambiente de desarrollo local - GUI-DGT-001 Guía de desarrollo para LinkBridge - GUI-DGT-004 Uso de prettier - GUI-DGT-005 Guía de clonado de bases de datos en PostgreSQL Variables de entorno Revisar el canal env en el Discord Departamental dentro del canal Zeitgeist para obtener las variables de entorno del Frontend y Backend más actualizadas.	Team Member	TS SP 2.2 VER SP 1.2 VAL SP 1.2
Desarrollo	1. Revisar todos los Requisitos No Funcionales (RNF) previamente identificados en el ERS. Las decisiones de desarrollo deben estar alineadas con los RNF para garantizar que el sistema cumpla con las expectativas de calidad. 2. Abrir los diagramas diseñados. 3. Revisar los criterios de aceptación en el ERS. 4. Abrir las pruebas diseñadas en la Matriz de Pruebas de Integración. 5. En caso de encontrar defectos de la fase de Análisis o Diseño, registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0.. Backend 1. Revisar si la el método a desarrollar ya está implementado. Para ello, revisar los siguientes módulos: entities, repositories, interfaces, services, controllers y routes. Consultar el Diagrama de Paquetes Backend para identifcar la ubicación de cada uno de los módulos. En caso que ya esté implementado el método, reutilizarlo y adaptarlo dónde sea necesario. Para asegurar que todo sigue funcionando, al terminar deberás correr las pruebas unitarias ya diseñadas. 2. Crear una nueva rama a partir de develop siguiendo el EST-BDT-006 Estándar para nombres de ramas. 3. Hacer un pull de develop con el comando git pull origin develop. 4. Tomar el tiempo efectivo utilizando el plugin Wakatime de VSCode. 5. Codificar siguiendo la checklists CHK-DGT-002 Verificación de Backend donde se incluyen los estándares de desarrollo. 6. Documentar el código conforme al EST-DGT-002 Estándar para Comentarios de Código con Doxygen. 7. Realizar las Pruebas Unitarias y las Pruebas de Integración del Back conforme al Plan de Pruebas. Para ello, utilizar las siguientes guías: - GUI-DGT-008 Guía de pruebas unitarias en TypeScript - GUI-GDT-007 Pruebas con Postman 8. Ejecutar las pruebas unitarias ya antes diseñadas y las nuevas con el comando pnpm test. En caso de que alguna prueba no pase, actuar conforme a lo siguiente: - Si la prueba fue desarrollada por alguien más, revisar los nuevos métodos desarrollados o los previamente adaptados conforme al punto 1, y corregirlos para asegurar que el método funcione de la manera esperada. - Si la prueba la desarrollaste, corregir el método desarrollado o las pruebas diseñadas dependiendo el caso. Una vez corregidos los errores, volver a correr todas las pruebas unitarias hasta que todas pasen. 9. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0.. 10. Registrar el tiempo efectivo en el PVG en Backend y Unit Testing para el tiempo de desarrollo de pruebas unitarias del backend. 11. Realizar un commit de los cambios realizados conforme al EST-BDT-007 Estándar para commits de código. 12. Realizar un push a la rama con el comando git push origin <nombre_rama>. Frontend 1. Revisar el componente o método a desarrollar ya está implementado. Para ello, revisar los siguientes módulos: hooks, types, utils, services, components/modules y components/common. Consultar el Diagrama de Paquetes Fronted para identifcar la ubicación de cada uno de los módulos. En caso que ya esté implementado el método, reutilizarlo y adaptarlo dónde sea necesario. Para asegurar que todo sigue funcionando, al terminar deberás correr las pruebas unitarias ya diseñadas. 2. Crear una nueva rama a partir de develop siguiendo el EST-BDT-006 Estándar para nombres de ramas. 3. Hacer un pull de develop con el comando git pull origin develop. 4. Tomar el tiempo efectivo utilizando el plugin Wakatime de VSCode. 5. Codificar siguiendo la checklists CHK-DGT-004 Verificación de Frontend donde se incluyen los estándares de desarrollo. 6. Documentar el código conforme al EST-DGT-002 Estándar para Comentarios de Código con Doxygen. 7. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 8. Registrar el tiempo efectivo en el PVG en Frontend. 9. Realizar un commit de los cambios realizados conforme al EST-BDT-007 Estándar para commits de código. 10. Realizar un push a la rama con el comando git push origin <nombre_rama>. Conexión 1. Hacer un pull de develop con el comando git pull origin develop. 2. Tomar el tiempo efectivo utilizando el plugin Wakatime de VSCode. 3. Realizar la conexión del Frontend con el Backend en la rama del Frontend. 4. Documentar el código conforme al EST-DGT-002 Estándar para Comentarios de Código con Doxygen. 5. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 6. Registrar el tiempo efectivo en el PVG en Conexión. 7. Actualizar la Matriz de Trazabilidad. 8. Realizar un commit de los cambios realizados conforme al EST-BDT-007 Estándar para commits de código. 9. Realizar un push a la rama con el comando git push origin <nombre_rama>.	Team Member	VER SP 1.3 TS SP 2.4 TS SP 3.1 PMC SP 1.1 RD SP 3.3 RD SP 3.5 CM SP 1.2 REQM SP 1.4 REQM SP 1.5
Verificación del Desarrollo	1. Verificar el código con la Checklist de Código correspondiente: - CHK-DGT-002 Verificación de Backend - CHK-DGT-004 Verificación de Frontend 2. En caso de encontrar defectos registrarlos en el Defect Log correspondiente y solucionarlos hasta que el número de defectos sea 0. - Defect Log Backend. - Defect Log Frontend. 3. Al terminar, registrar el tiempo en el PVG en Backend, Unit Testing, Frontend o Conexión dependiendo dónde se hayan realizado los cambios.	Team Member	VER SP 1.1 VER SP 1.3 VER SP 3.1 VER SP 3.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Validación del Desarrollo	1. Validar el código con las personas capacitadas; estás personas son los AO y Ex-AOs debido a que conocen a detalle la arquitectura del proyecto, el stack tecnológico y están o estuvieron activos en la definición de los mismos.. Para ello, utilizar la Checklist de Código correspondiente: - CHK-DGT-002 Verificación de Backend - CHK-DGT-004 Verificación de Frontend 2. En caso de encontrar defectos registrarlos en el Defect Log correspondiente y solucionarlos hasta que el número de defectos sea 0. - Defect Log Backend - Defect Log Frontend 3. Al terminar, registrar el tiempo en el PVG en Backend, Unit Testing, Frontend o Conexión dependiendo dónde se hayan realizado los cambios.	Team Member	VER SP 2.1 VER SP 2.2 VER SP 2.3 VAL SP 1.1 VAL SP 1.3 VAL 2.1 VAL 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Pruebas	1. Abrir el Plan de Pruebas y ejecutar las siguientes pruebas: - Pruebas de Integración de Frontend: solicitar a un Team Member adicional que ejecute las pruebas de integración de Frontend. - Pruebas de Sistema en Voz Alta: realizar pruebas en voz alta con algún usuario externo al proyecto. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. 3. Registrar el tiempo efectivo en el PVG en Testing.	Team Member	PPQA SP 1.2 VER SP 1.3 VER SP 3.1 VER SP 3.2 VAL SP 2.1 VAL SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Entrega	Revisar que el requisito funcional desarrollado cumpla con la definición de Done. En caso de no hacerlo, realizar los cambios pertinentes. Backend 1. Realizar un pull de la rama develop a tu rama local y solucionar posibles conflictos. Una vez no haya conflictos, realizar un push de tu rama local a la rama remota. 2. Abrir un Pull Request a la rama developen el repositorio del Backend de GitHub siguiendo el estándar EST-DGT-006 Envío de Pull Requests DotGeist 3. Solicitar a un Team Member que revise el Pull Request utilizando la CHK-DGT-005 Revisión de Pull Request. 4. En caso de encontrar defectos registrarlos en el Defect Log Backend y solucionarlos hasta que el número de defectos sea 0. 5. Registrar el tiempo efectivo en el PVG en Entrega. 6. Agregar a las columnas de Desarrollo y Pruebas de la Matriz de Trazabilidad de Requerimientos el enlace del Pull Request del Backend Frontend 1. Realizar un pull de la rama develop a tu rama local y solucionar posibles conflictos. Una vez no haya conflictos, realizar un push de tu rama local a la rama remota. 2. Abrir un Pull Request a la rama develop en el repositorio del Frontend de GitHub siguiendo el estándar EST-DGT-006 Envío de Pull Requests DotGeist 3. Solicitar a un Team Member que revise el Pull Request utilizando la CHK-DGT-005 Revisión de Pull Request. 4. En caso de encontrar defectos registrarlos en el Defect Log Frontend y solucionarlos hasta que el número de defectos sea 0. 5. Registrar el tiempo efectivo en el PVG en Entrega. 6. Agregar a la columna de Desarrollo de la Matriz de Trazabilidad de Requerimientos el enlace del Pull Request del Frontend. Actualizar el Status del RF en la Matriz de Trazabilidad de Requerimientos y marcarlo como Done.	Team Memeber	CM SP 1.2 CM SP 2.1 CM SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.4 REQM SP 1.5
Despliegue	Backend 1. Abrir un Pull Request de develop a la rama staging en el repositorio del Backend de GitHub siguiendo el estándar EST-DGT-006 Envío de Pull Requests DotGeist 2. Solicitar al AO que revise y acepte el Pull Request. 3. En caso de encontrar defectos registrarlos en el Defect Log Backend y solucionarlos hasta que el número de defectos sea 0. Para solucionarlos, crear una nueva rama de develop siguiendo el EST-BDT-006 Estándar para nombres de ramas y una vez se corrijan los defectos, regresar a la fase de Verificación de Desarrollo. Frontend 1. Abrir un Pull Request de develop a la rama staging en el repositorio del Frontend de GitHub siguiendo el estándar EST-DGT-006 Envío de Pull Requests DotGeist 2. Solicitar al AO que revise y acepte el Pull Request. 3. En caso de encontrar defectos registrarlos en el Defect Log Frontend y solucionarlos hasta que el número de defectos sea 0. Para solucionarlos, crear una nueva rama de develop siguiendo el EST-BDT-006 Estándar para nombres de ramas y una vez se corrijan los defectos, regresar a la fase de Verificación de Desarrollo.	Team Memeber, AO	CM SP 1.2 CM SP 2.1 CM SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5
Pruebas en Despliegue	1. Abrir el Plan de Pruebas y ejecutar las siguientes pruebas: - Pruebas de Integración de Frontend: solicitar a un Team Member adicional que ejecute las pruebas de integración de Frontend. - Pruebas de Sistema en Voz Alta: realizar pruebas en voz alta con algún usuario externo al proyecto. - Pruebas de Sistema Con Usuarios Expertos: realizar pruebas en voz alta con usuarios expertos. 2. En caso de encontrar defectos registrarlos en el Defect Log y solucionarlos hasta que el número de defectos sea 0. Para solucionarlos, crear una nueva rama de develop siguiendo el EST-BDT-006 Estándar para nombres de ramas y una vez se corrijan los defectos, regresar a la fase de Verificación de Desarrollo. 3. Registrar el tiempo efectivo en el PVG en Testing.	Team Member	PPQA SP 1.2 VER SP 1.3 VER SP 3.1 VER SP 3.2 VAL SP 2.1 VAL SP 2.2 PMC SP 1.1 RD SP 3.3 RD SP 3.5 REQM SP 1.5

Control de cambios

Versión	Cambio realizado	Análisis	Autor	Revisor(es)	Fecha de cambio
v 1.0	Creación del proceso	N/A	Sebastián Flores Daniel Hurtado Diego Perdomo Rodrigo Terán Sergio Garnica Carlos Salguero Arturo Diaz Armando Rosas Ian Padrón		14/05/2024
v 2.0	Agregar fases de Despliegue y Pruebas en Despliegue	Como parte del proceso completo de desarrollo, se deben realizar pruebas en staging. Para ello, se agregaron las fases faltantes	Sergio Garnica	Alejandra Cabrera, Denisse Domínguez	22/05/2024
v 2.1	Agregar practicas de RD	Se agrega practica SP 3.5	Mike Tena		27/05/2024
v 2.2	Ortografía e identificación	Actualizar faltas de ortografía	Sergio Garnica González	Carlos Salguero	31/05/2024
v 2.3	Agregar nombre de persona faltante en la creación	Falto el nombre de un persona que participo en la definición de esta forma de trabajo, igualmente correción de ortografia y nombres	Diego Perdomo Salcedo	Carlos Salguero	31/05/2024
v 2.4	Se elimino una fase que no se ejecutaba	En la auditoría AUD-033 se identificó que una fase del proceso no se ejecutaba, por lo cual se eliminó para atender la no conformidad.	Sebastian Flores	Carlos Salguero	05/06/2024
v 2.5	Se añade prácticas de CM	Identificar las fases en la que se usa CM	Sergio Garnica		07/06/2024
v 3.0	Se añade prácticas de REQM	Se identifican las fases que usan REQM	Olimpia García	Ale Cabrera	07/06/2024
v 3.1	Se añade prácticas de REQM	Se identifican las fases que usan REQM 1.4 y 1.5	Sergio Garnica	Ale Cabrera	07/06/2024