PRO-BDT-004 Estimación y definición de requerimientos
v 9.1 / REQM, RD, TS, PP, VAL
Propósito
El propósito del proceso es establecer, priorizar, validar y estimar los requerimientos que satisfagan la necesidad del cliente.
Notas introductorias
Este proceso usa diversas terminologías del libro Ingeniería del Software de Ian Sommerville.
- Requisitos a nivel de usuario: Requerimientos funcionales en forma de una historia en lenguaje natural, que expresa a grandes rasgos la funcionalidad deseada.
- Requisitos a nivel de sistema: Una especificación más detallada de un requsito funcional, dónde existe una serie de pasos específicos que debe de realizar el sistema.
Los requerimientos y cambios a requerimientos vendrán solamente de los actores identificados en el Impact Mapping.
Antes de estimar es importarte revisar el WBS para tener un entendimiento real de lo que implica implementar un requerimiento.
Involucrados
Team Members, Architecture Owner y Product Owner.
Entradas
- Acta de proyecto con la visión descrita.
- GUI-BDT-017
- GUI-BDT-024
- Estándar RTM
Salidas
- WBS Requerimiento
- Impact mapping
- Documento de Especificación de Requerimiento de Software (ERS)
- RTM
- Compromisos con Stakeholders actualizado: Link CR, Link Zeitgeist
Descripción
| Fase | Actividades | Responsables | Prácticas Asociadas al CMMI |
|---|---|---|---|
| Definición | 1. Desarrollar un WBS siguiendo la GUI-BDT-024, donde se definan los paquetes de trabajo de cada fase del desarrollo de un requerimiento o historia de usuario. 2. Utilizando la técnica del Impact Mapping transformar la necesidad del cliente y los objetivos del proyecto en relaciones entre actores y módulos. Los objetivos del proyecto se pueden definir usando el PRO-BDT-005. 3. Se deben identificar las características de los usuarios, restricciones y dependencias del sistema. 4. Cada módulo deberá después transformarse a historias de usuario usando el formato "Yo como usuario quiero lo que quiero hacerpara el objetivo". Estos serán los requerimientos funcionales. 5. Definir los requerimientos funcionales en una Especificación de Requerimientos del Sistema (ERS) usando el estándar IEEE 830-1998.Puedes consultar la F-PRO-BDT-004A que demuestra el contenido de dicho documento. 6. Añadir a cada requerimiento funcional criterios de aceptación en forma de requerimientos a nivel sistema. Los criterios de aceptación marcaran cuando una funcionalidad se considere completada, enmarca lo que una historia de usuario debe hacer de manera más detallada y sus limitantes. 7. En el mismo documento se deben incluir los requerimientos no funcionales, comunmente conocidos como atributos de calidad. Deberán ser escritos con una métrica para poder evaluar su cumplimiento posteriormente. También deben estar orientados a los factores de negocio y a la misión del proyecto. 8. Realizar la primera estimación de los requerimientos de acuerdo a la GUI-BDT-017. | Team Members, PO, AO | PP SP 1.1 PP SP 1.2 PP SP 1.4 PP SP 2.3 PP SP 2.4 REQM SP 1.1 REQM SP 1.2 RD SP 1.2 RD SP 2.1 RD SP 2.2 RD SP 3.1 RD SP 3.2 RD SP 3.3 TS SP 1.2 |
| Priorización | 1. El PO prioriza los requerimientos que atienden la necesidad del cliente dividiéndolos en las versiones del producto que sean necesarias: MVP, MBI 1, MBI 2, MBI#. Es importante que la primera verisón del producto (MVP) satisfaga el objetivo del proyecto y el tamaño del MVP sea realizable dentro del periodo definido de acuerdo a las estimaciones realizadas. | PO | REQM SP 1.1 |
| Trazabilidad | 1. Definir una Matriz de Trazabilidad (RTM) siguiendo el estándar. 2. Escribir todos los requerimientos funcionales y no funcionales en la Matriz de Trazabilidad (RTM). Se deberá incluir un espacio para cada una de las fases por las que pasa el requerimiento previamente definidas en el WBS. Las fases definidas normalmente son análisis, diseño, desarrollo, pruebas y entrega. 3. Escribir las definiciones de Ready y Done para cada proyecto. Estas definiciones indicarán el estado del requerimiento. Si la validación no se incluye en la definición de Done deberá incluirse una columna en la RTM que indique si un requerimiento está validado por el cliente o no. | Team Members | REQM SP 1.4 RD SP 2.1 RD SP 2.2 RD SP 3.3 |
| Diseño de Interfaces | 1. Si el conocimiento sobre la arquitectura definida en el PRO-BDT-005 lo permite diseñar las interfaces del sistema. Los wireframes pueden ser de alto o bajo nivel dependiendo de la necesidades. 2. Las interfaces serán diseñadas teniendo en cuenta los requisitos no funcionales. Si se realiza en esta fase se puede utilizar la Checklist de UI/UX. Si no se realizará en la fase de análisis del proceso de desarrollo. 3. Cada interfaz o wireframe deberá indicar a cual requisito funcional pertenece. | Team Members | RD SP 2.3 TS SP 2.3 |
| Validación | 1. Los team members revisan los requerimientos, las estimaciones y los criterios de aceptación. Así como la división de los requerimientos en los incrementos del producto verificando su viabilidad. 2. Validar el contenido de la Especificación de Requerimientos del Sistema (ERS) y las interfaces del sistema con el cliente por medio de una junta, utilizar el PRO-BDT-008. Se debe registrar la revisión en el log de Compromisos con Stakeholders Link CR, Link Zeitgeist donde el cliente debe firmar el respectivo documento aceptando las Historias de Usuario. | PO, Team Members | REQM SP 1.2 RD SP 3.3 RD SP 3.5 VAL SP 2.1 |
Control de cambios
| Versión | Cambio realizado | Análisis | Autor del cambio | Revisor(es) | Fecha de cambio |
|---|---|---|---|---|---|
| v 1.0 | Realización del proceso. | N/A | Damariz Licea Alejandra Cabrera Uri Gopar Ramona Nájera | 24/02/2024 | |
| v 2.0 | Se quitaron las fases de análisis de necesidad y definición de visión para llevarlas a cabo en el proceso PRO-BDT-005 Definir visión del proyecto y PRO-BDT-003 Identificación de la necesidad del cliente. | N/A | Carlos Velasco | Alejandra Cabrera | 25/02/2024 |
| v 3.0 | Se usa la denominación del autor Ian Sommerville, “requerimientos de usuario” y “requerimientos de sistema”. | N/A | Ricardo Fernández | Aprobado en Junta Departamental | 26/02/2024 |
| v 4.0 | Intercambio en la secuencia de fases: primero se validan los requerimientos con el cliente y después se priorizan por el PO | N/A | Ricardo Fernández | Ramona Nájera Armando Rosas | 26/02/2024 |
| v 5.0 | La entrada cambio de una necesidad a algo tangible. Se agrego el wbs. Se renombraron las fases. | N/A | Alejandra Cabrera | Ricardo Fernández | 27/02/2024 |
| v 5.1 | Se agregaron notas introductorias explicando conceptos del libro Ingenieria de Software de Ian Sommerville. | N/A | Ricardo Fernández | Daniel Cajas | 05/03/2024 |
| v 6.0 | Aseguración de las fases en una guía F-PRO-BDT-004A con base en IEEE 830. Entradas y salidas tangibles. Cambio del orden de las fases | N/A | Ricardo Fernández Alejandra Cabrera | Olimpia García | 06/03/2024 |
| v 7.0 | Se refrasea la validación de los requerimientos | N/A | Olimpia Garcia | Yuna Chung | 23/04/2024 |
| v 7.1 | Actualizar Versión | N/A | Carlos Velasco | David Langarica | 30/04/2024 |
| v 7.2 | Refrasear el paso número 2 | Retro de SCAMPI | Ricardo Fernández | 17/05/2024 | |
| v 7.3 | Correción Auditoria 14 | Cambio entrada y SP en fase | Azul Rosales | Daniel Fuentes | 20/05/2024 |
| v 8.0 | Agregar validación de historias de usuario | N/A | Mafer Moreno | Diego Perdomo | 21/05/2024 |
| v 9.0 | Cambio de las fases del proceso: añade diseño de interfaces y trazabilidad. | Se hace más claro el proceso de transformar las necesidades a requerimientos. Se incluyen atributos de calidad, diseño de interfaces, trazabilidad, definición de Ready y Done, y validación usando el PRO-BDT-008. | Alejandra Cabrera | Carlos Salguero | 24/05/2024 |
| v 9.1 | Añadir prácticas faltantes y se definen entradas | En la estimación falta PP 1.4 | Alejandra Cabrera | Ricardo Rosales | 07/06/2024 |