05 - Ingeniería de Requerimientos: Especificación
¿Qué hacer después de guardar la información?
Resumen de la sección: En esta sección, el hablante menciona que no sabe qué hacer después de guardar la información en un módulo. Se le pide al oyente que invente algo y luego lo cambie una semana después. También se anima a suscribirse al canal, darle click a la campanita para recibir notificaciones y compartir el contenido.
Pasos a seguir:
- Inventar algo para realizar después de guardar la información en el módulo.
- Cambiarlo una semana después.
- Suscribirse al canal y activar las notificaciones.
- Compartir el contenido con conocidos.
Importancia de documentar los requerimientos
Resumen de la sección: El hablante destaca la importancia de documentar los requerimientos en un proyecto. Menciona que es imposible que el equipo memorice toda la información y que surgirán dudas y suposiciones. No resolver estas diferencias rápidamente puede llevar a retrasos e insatisfacción. Además, menciona que es importante tener información sobre cómo se tomaron las decisiones en sistemas ya construidos.
Puntos clave:
- Documentar los acuerdos sobre lo que debe hacer el sistema y las restricciones que tiene.
- Evitar retrasos e insatisfacción resolviendo rápidamente las diferencias y dudas.
- Tener información sobre cómo se tomaron las decisiones en sistemas ya construidos.
Preguntas importantes para especificar los requerimientos
Resumen de la sección: El hablante menciona que una de las mayores dificultades para los equipos es definir lo que se debe especificar en los requerimientos. Destaca la importancia de responder preguntas como qué se va a resolver, en quiénes estamos teniendo impacto, qué quieren hacer los usuarios y qué debe hacer el sistema.
Puntos clave:
- Responder preguntas sobre lo que se va a resolver y por qué es importante.
- Identificar a quiénes estamos teniendo impacto.
- Entender qué quieren hacer los usuarios y qué debe hacer el sistema.
Información necesaria para entender cómo se tomaron las decisiones
Resumen de la sección: El hablante menciona que es importante tener información que permita entender cómo se tomaron las decisiones en sistemas ya construidos. Se deben especificar los requerimientos y documentar acuerdos sobre lo que debe hacer el sistema, las restricciones tecnológicas, entre otros aspectos.
Puntos clave:
- Tener información sobre cómo se tomaron las decisiones en sistemas ya construidos.
- Especificar requerimientos y documentar acuerdos sobre lo que debe hacer el sistema.
- Considerar restricciones tecnológicas y estándares.
Especificación de los requerimientos
Resumen de la sección: El hablante introduce el tema de la especificación de los requerimientos. Menciona que esta etapa consiste en documentar lo que se va a hacer y por qué es importante. Los requerimientos de negocio marcan la dirección del proyecto y establecen objetivos para alcanzarlos.
Puntos clave:
- Documentar lo que se va a hacer y por qué es importante.
- Los requerimientos de negocio marcan la dirección del proyecto y establecen objetivos.
Contenido de una especificación de visión
Resumen de la sección: El hablante menciona que en una especificación de visión se debe incluir un resumen ejecutivo con el estado actual y la problemática, el estado deseado expresado en objetivos SMART, el enunciado que describe la visión del software, las funciones principales y los riesgos del proyecto.
Puntos clave:
- Incluir un resumen ejecutivo con información sobre el estado actual y la problemática.
- Establecer objetivos SMART para el estado deseado.
- Describir la visión del software, las funciones principales y los riesgos del proyecto.
Especificación de funciones principales
Resumen de la sección: El hablante menciona que en una especificación de funciones principales se deben describir las funciones que ejecutará el software. Se destaca que esta especificación hablará en el lenguaje del negocio y debe evitar incluir muchos conceptos técnicos.
Puntos clave:
- Describir las funciones principales que ejecutará el software.
- Hablar en el lenguaje del negocio y evitar conceptos técnicos excesivos.
Identificación de stakeholders
Resumen de la sección: El hablante menciona que todas las decisiones tomadas para un producto tienen un impacto e influencia por parte de los stakeholders. Se debe establecer un acuerdo sobre quiénes son los usuarios directos, patrocinadores, definidores de reglas, entre otros.
Puntos clave:
- Identificar quiénes son los usuarios directos, patrocinadores y definidores de reglas.
- Establecer un acuerdo sobre el rol de cada stakeholder.
Usuarios directos e indirectos
Resumen de la sección: El hablante menciona que los usuarios directos son aquellos que utilizarán las funciones del software, mientras que los usuarios indirectos recibirán beneficios aunque no lo utilicen directamente. También destaca la importancia de incluir información adicional sobre intereses, actitudes y restricciones de los stakeholders.
Puntos clave:
- Diferenciar entre usuarios directos e indirectos.
- Incluir información adicional sobre intereses, actitudes y restricciones de los stakeholders.
Especificación de requerimientos de usuario
Resumen de la sección: El hablante menciona que en la especificación de requerimientos de usuario se deben documentar los procesos y objetivos que quieren completar a través del software. Se enfatiza en centrarse en actividades completas del usuario en lugar de funciones individuales del software.
Puntos clave:
- Documentar procesos y objetivos que quieren completar a través del software.
- Centrarse en actividades completas del usuario en lugar de funciones individuales del software.
Detalle de los procesos y funciones del software
Resumen de la sección: En esta sección se habla sobre la importancia de especificar las funciones que debe tener el software para permitir a los usuarios completar sus actividades. Se menciona que la especificación de estas funciones nos ayuda a comprender qué hará la aplicación en sus diferentes elementos.
Funciones del software
- La herramienta de casos de uso es útil para obtener un mayor detalle sobre los procesos y funciones del software.
- El software debe ofrecer diferentes funciones para permitir que los usuarios completen sus actividades.
- Las funciones individuales pueden incluir escribir texto, elegir el tipo de fuente, cambiar el tamaño de la fuente, agregar imágenes y videos, alinear el texto, cambiar el color del fondo, guardar un borrador, seleccionar destinatarios, buscar destinatarios registrados, crear nuevos destinatarios y enviar correos.
- Es importante describir el comportamiento de las funciones en escenarios normales, errores y excepciones.
Ambiente en el que operará el sistema
Resumen de la sección: En esta sección se habla sobre la importancia de comprender el ambiente en el que operará el sistema. Se mencionan aspectos como las características de los dispositivos en los que se ejecutará el software, las características de las redes de comunicación entre los dispositivos y otros elementos relacionados con el entorno tecnológico.
Ambiente operativo del sistema
- Es necesario comprender las características de los dispositivos en los que se ejecutará el software.
- También es importante conocer las características de las redes de comunicación entre los diferentes dispositivos.
- Se debe tener en cuenta la localización de los usuarios, los días y horarios de mayor uso del sistema y el ecosistema de software con el que convive nuestro producto.
- Si el sistema se comunicará con otras aplicaciones de software y hardware, es necesario especificar cuáles son esas aplicaciones y las características de las interfaces que se utilizarán.
Restricciones tecnológicas
Resumen de la sección: En esta sección se habla sobre las restricciones tecnológicas que pueden afectar el desarrollo del software. Se mencionan aspectos como la compatibilidad con diferentes dispositivos y programas, dependencias con componentes y bibliotecas de terceros, restricciones de recursos y arquitecturas específicas.
Restricciones tecnológicas
- Es importante considerar la compatibilidad del software en diferentes dispositivos y programas.
- Se deben especificar las dependencias con componentes y bibliotecas de terceros, indicando su versión y ubicación.
- También es relevante tener en cuenta restricciones como la cantidad de memoria, capacidad de procesamiento, ancho de banda y resolución de pantallas.
- Las arquitecturas específicas del hardware y sistemas operativos también deben ser consideradas.
Evaluación del cumplimiento de requerimientos no funcionales
Resumen de la sección: En esta sección se habla sobre cómo evaluar el cumplimiento de los requerimientos no funcionales. Se menciona que estos requerimientos son susceptibles a ambigüedades y se sugiere especificarlos con parámetros objetivos y medibles.
Evaluación requerimientos no funcionales
- Los requerimientos no funcionales, como la seguridad, usabilidad, rendimiento y ausencia de fallos, deben ser especificados con parámetros objetivos y medibles.
- Se pueden incluir escenarios de prueba para evaluar el cumplimiento de estos requerimientos.
- También se menciona que algunos elementos del sistema deben apegarse a estándares establecidos, como la interfaz gráfica o los mensajes entre sistemas.
Suposiciones y documentación
Resumen de la sección: En esta sección se habla sobre la importancia de hacer suposiciones claras en la especificación de los requerimientos y sobre la documentación necesaria. Se menciona que es importante revisar continuamente las suposiciones y agregar nuevas conforme surjan.
Suposiciones y documentación
- Es importante hacer un apartado en la especificación para anotar las suposiciones que aún no han sido resueltas.
- Estas suposiciones deben ser revisadas continuamente para eliminar las que ya han sido respondidas y agregar nuevas conforme surjan.
- La documentación es importante para comprender el sistema y colaborar con el equipo durante el desarrollo.
- Se sugiere incluir referencias a manuales de operación, bibliotecas de ayuda, foros de apoyo y otra información relevante.
Requerimientos y documentación
Resumen de la sección: En esta sección, se habla sobre los requerimientos y la importancia de documentarlos adecuadamente. Se menciona que la información documentada debe tener un nivel de detalle suficiente para que el equipo pueda responder preguntas comunes en el proyecto. Además, se destaca que la especificación de los requerimientos no está escrita en piedra y puede cambiar a lo largo del tiempo. Se recomienda utilizar una herramienta como una wiki para facilitar la búsqueda, colaboración, acceso y gestión de cambios en la documentación.
Características recomendadas para una herramienta de documentación
- La herramienta debe facilitar la búsqueda rápida y fácil de información.
- Debe permitir la colaboración entre el equipo.
- Debe ser fácil de acceder y compartir.
- Debe gestionar los cambios de versiones automáticamente.
Recomendación: Utilizar una wiki
Se recomienda utilizar una wiki debido a que ya tiene integradas todas las características mencionadas anteriormente. Si aún hay escepticismo sobre seguir estas recomendaciones, se plantea una pregunta clave: "¿Qué información sería suficiente para que mi equipo entienda los acuerdos del sistema en todo momento?". La respuesta a esta pregunta será tu forma de especificar los requerimientos.
Validación de los requerimientos
Resumen de la sección: En esta sección, se menciona que la validación de los requerimientos es importante para asegurarse de haberlos entendido correctamente y completos. No hay más contenido relevante en esta parte del video.
Nos vemos en la siguiente sección.
[Música] [Aplausos]