Speaker A
Bueno, entonces en esta actividad de aprendizaje seguimos en la misma competencia. Esta evidencia se llama "Taller de instrumentos de especificación de requisitos".
Sesión formativa sobre el SRS (Especificación de Requisitos de Software) según la ISO/IEC/IEEE 29148, con ejemplo de un sistema de agendamiento de citas para una IPS. Describe qué debe hacer el softwa
Key Takeaways
- El SRS define qué debe hacer el software y sirve de guía para el equipo de desarrollo, reduciendo ambigüedades y retrabajos.
- La estructura del SRS está estandarizada por la ISO/IEC/IEEE 29148 y debe respetarse con la plantilla dada.
- El SRS debe mantener coherencia con la elicitación previa y con el proyecto formativo del grupo.
What the video covers
- La instructora Martha Paz presenta la evidencia 'Taller de instrumentos de especificación de requisitos' (GA1-220501092 AA1 EV02).
- El SRS (Software Requirements Specification) describe qué debe hacer el software antes de programarlo, pero no el cómo, que se detalla en historias de usuario funcionales.
- Se usa la analogía de un arquitecto y un plano de casa para explicar la función del SRS como guía para el equipo de desarrollo.
- Se plantea un caso: sistema web de agendamiento de citas para una entidad prestadora de servicios de salud, que reduzca duplicidad y pérdida de citas actualmente gestionadas en Excel o agendas manuales.
- Las tres bases a considerar antes de construir: la necesidad, la propuesta y los límites del producto.
- La estructura del documento sigue la norma ISO/IEC/IEEE 29148 y una plantilla proporcionada, que no debe alterarse.
- Apartados abordados: propósito del documento, características de los usuarios (paciente, facturador, etc.), funcionalidades y limitaciones.
- Se mencionan normativas aplicables al contexto colombiano, como la Ley 1581 (datos personales) y la Resolución 1733 (historias clínicas).
- Recomendaciones de usabilidad: sistema fácil de entender, poco agresivo visualmente y con pocos botones.
- Instrucciones de entrega: incluir el prompt completo si se usó IA como apoyo, validar ortografía y redacción, y verificar coherencia con el proyecto integral.
Chapters
- 00:00Introducción a la evidencia y the taller
- 01:54Qué es un SRS y su función
- 05:43Analogía del plano arquitectónico
- 09:22Necesidad, propuesta y límites del proyecto
- 14:34Estructura del documento según ISO/IEC/IEEE 29148
- 17:16Propósito, usuarios y limitaciones
- 22:53Normativa, usabilidad y recomendaciones de entrega
Full Transcript — Download SRT & Markdown
Speaker A
¿Listo? Entonces, ¿qué es un CRS? Un un CRS es un documento que describe qué debe hacer el software antes de construir, ¿listo?
Speaker A
¿Listo? Entonces, ¿qué es un SRS? Un SRS es un documento que describe qué debe hacer el software antes de construirlo. ¿Listo?
Speaker A
Entonces, eh si yo dije que voy a hacer un software para una entidad eh prestadora de servicios médicos de salud, pues yo eh la idea es que ustedes continúen en esa línea de del proyecto.
Speaker A
La idea de un SRS es mantener coherencia con el proyecto formativo que ustedes ya iniciaron en la evidencia anterior de elicitación.
Speaker A
Y al ser el problema gestionar las citas, la solución debe responder a esa necesidad.
Speaker A
Entonces, si yo dije que voy a hacer un software para una entidad prestadora de servicios de salud, la idea es que ustedes continúen en esa línea del proyecto.
Speaker A
Es un documento que se escribe antes de programar. Antes de, o sea, una vez hacen proceso de elicitación, aquí es donde se empieza a estructurar como un poquito la parte técnica, ¿listo? De qué debe hacer el sistema.
Speaker A
Por ejemplo, si estamos hablando de un sistema de hospital o de atención, el problema en sí es gestionar las citas, ¿sí? Fue lo que dijeron en elicitación.
Speaker A
Cuando uno va a hacer una casa, antes de colocar un ladrillo, pues normalmente uno contrata un arquitecto y hace un plano, ¿sí?
Speaker A
Y al ser el problema gestionar las citas, la solución debe responder a esa necesidad.
Speaker A
documento SRS. Se mira detenidamente cuáles son los materiales, cómo vamos a distribuir ese plan, esa casa en ese plano, en ese terreno, y así lo plasmamos en el documento.
Speaker A
Entonces, empecemos por lo básico. Primero, el SRS, cuyas siglas en inglés son Software Requirements Specification, que en español son especificaciones de requerimientos de software, ¿sí?
Speaker A
Y es, se describe lo que el sistema debe hacer, pero no el cómo. Ese es el SRS, se describe lo que debe hacer, pero no el cómo. Instructora, ¿y por qué no va el cómo? Porque el cómo lo
Speaker A
Es un documento que se escribe antes de programar. Una vez hecho el proceso de elicitación, aquí es donde se empieza a estructurar la parte técnica, ¿listo? De qué debe hacer el sistema.
Speaker A
También ayuda a que los usuarios interesados y el equipo de desarrollo comprendan como tal la propuesta o el desarrollo del software y reduce ambigüedades y ayuda a cortar, digamos, a acordar los límites del producto.
Speaker A
Veámoslo desde este punto de vista para que lo vayamos entendiendo, con una analogía.
Speaker A
¿Quién me da una opinión allí? No se tendría como una guía de dónde comenzar, como no sé, una aplicación en usuario y contraseña o más o menos así.
Speaker A
Cuando uno va a hacer una casa, antes de colocar un ladrillo, normalmente contrata un arquitecto y hace un plano, ¿sí?
Speaker A
O a lo que interprete el equipo de desarrollo. Lo dijimos la sesión pasada. Doctora, de pronto puedan programar mal eh lo que van a hacer los desarrolladores.
Speaker A
En ese plano se distribuye cómo se va a construir la casa: la habitación va a quedar en tal lado, de tanto por tanto, aquí va a quedar un baño, ¿sí? Esa distribución que se hace en el plano es lo que se hace en este documento SRS. Se mira detenidamente cuáles son los materiales, cómo vamos a distribuir ese plano, esa casa, en ese terreno, y así lo plasmamos en el documento.
Speaker A
¿Sí? Entonces, por eso la importancia de este documento. ¿Hasta aquí vamos bien? A ver, se me perdió la ventana.
Speaker A
Si ustedes leyeron el material de formación, hay una frase muy importante que es la que se tienen que grabar y con la que van a empezar de aquí en adelante.
Speaker A
Y vamos a hacer el ejemplo con lo que les estábamos con lo que les estaba hablando, de supongamos que este proyecto que vamos a hacer es de atención ambulatoria, ¿sí? De agendamiento de citas.
Speaker A
Se describe lo que el sistema debe hacer, pero no el cómo. Ese es el SRS: se describe lo que debe hacer, pero no el cómo. Instructora, ¿y por qué no va el cómo? Porque el cómo lo detallamos en las historias de usuario funcionales, ¿listo?
Speaker A
Excel, no está compartida en un drive que digamos pues que pueden ver en línea las dos personas que estén atendiendo o las personas que que atiendan allí la ventanilla.
Speaker A
Entonces, un SRS es un documento que describe esas características y condiciones para que ese producto de software pueda funcionar.
Speaker A
Entonces la propuesta que se hizo es que se iba a hacer un sistema de información web que permita organizar las citas y consultar los horarios disponibles.
Speaker A
También ayuda a que los usuarios interesados y el equipo de desarrollo comprendan la propuesta o el desarrollo del software, reduce ambigüedades y ayuda a acordar los límites del producto.
Speaker A
La primera es la necesidad. La necesidad es lo que siempre nos vamos que preguntar, qué problema específico buscamos resolver. Sí, entonces los usuarios tienen dificultad para organizar las citas. Ya sabemos que esa es la situación.
Speaker A
Entonces, ¿por qué esto es importante? Si en la elicitación, ¿qué pasaría si el equipo de desarrollo empieza a programar sin saber por dónde iniciar y solamente con el material de elicitación?
Speaker A
Listo, ya dijimos que vamos a sol como qué vamos a solucionar y qué vamos a plantear.
Speaker A
¿Quién me da una opinión? Pues no tendrían una guía de dónde comenzar, como, por ejemplo, una aplicación de usuario y contraseña, más o menos así.
Speaker A
Recuerden que hay citas particulares o si son por EPS se pagan cuotas moderadoras, copagos, entre otras. Toda esta información que les estoy diciendo se levantó en el proceso de licitación.
Speaker A
Más allá de que no tengan una guía, ese es un punto, pero ¿qué más puede suceder cuando empiezan a programar sin saber qué es lo que tienen que hacer, o a lo que interprete el equipo de desarrollo? Lo dijimos la sesión pasada: de pronto puedan programar mal lo que van a hacer los desarrolladores.
Speaker A
tenemos la necesidad, la propuesta y los límites. Esos son las tres bases que siempre debemos tener en cuenta, que nos debemos preguntar antes de iniciar la construcción de la evidencia.
Speaker A
Exactamente, podemos interpretar de manera diferente los requerimientos funcionales. Y eso genera retrasos y reprocesos, que en el tiempo son costos.
Speaker A
estipulado por la triple E, que es el 29 148 ¿cierto? Esa estructura de ese documento no nos lo inventamos, ya está establecido y tiene unos ítems, ¿sí? Si ustedes se fijan al lado izquierdo, está esa tabla que es del material de formación.
Speaker A
Entonces, por eso la importancia de este documento. ¿Hasta aquí vamos bien? A ver, se me perdió la ventana.
Speaker A
A su derecha, van a ver una estructura que dice material de la tabla 6 y nuestra plantilla.
Speaker A
Listo. Bueno. Entonces, el SRS normalmente debe mantener esa coherencia con el proyecto que ustedes tienen. Ya les había dicho, pero se me pasó.
Speaker A
ustedes van a modificar y van a plasmar allí su documento. La plantilla no me la vayan a alterar, por favor.
Speaker A
Vamos a hacer el ejemplo con lo que les estaba hablando: supongamos que este proyecto es de atención ambulatoria, ¿sí? De agendamiento de citas.
Speaker A
Hoy no vamos a detallar requisitos funcionales, eso es para la próxima sesión ¿sí? Entonces, en esa plantilla que ustedes van a encontrar vamos a hacer el proceso de cada uno de los puntos que tienen que desarrollar, tomando en cuenta el
Speaker A
La idea es que, con este sistema de información, el consultorio o la entidad, la IPS, pueda registrar las citas en diferentes medios y que no se dupliquen ni se pierdan, como ocurre actualmente. Hoy las diligencian en una hoja de cálculo de Excel que no está compartida en un Drive donde puedan ver en línea las dos personas que están atendiendo o las personas que atienden en la ventanilla.
Speaker A
separadas o manuales, ¿sí? Entonces, se pierden las citas, hay registros incompletos, errores al cobrar, eh etcétera, etcétera.
Speaker A
En algunas ocasiones también las llevan a mano en una agenda, y eso hace que las citas se dupliquen o se pierdan.
Speaker A
clínica y luego hay un proceso de cobro, sea particular o sea por eh la por la EPS ¿listo?
Speaker A
La propuesta que se hizo es un sistema de información web que permita organizar las citas y consultar los horarios disponibles.
Speaker A
Entonces, recuerden, tengo una necesidad, tengo una propuesta y tengo un límite. Cada sección, de cómo van a leer esta plantilla, cada sección trae cuatro partes.
Speaker A
Si ustedes se fijan, ese es el ejemplo. Si se fijan, hay tres ventanitas aquí.
Speaker A
Aquí hay una redacción muy sucinta, pero muy detallada, donde explica la información que va en ese apartado o en esa sección.
Speaker A
La primera es la necesidad. La necesidad es lo que siempre nos vamos a preguntar: qué problema específico buscamos resolver. Los usuarios tienen dificultad para organizar las citas. Ya sabemos que esa es la situación.
Speaker A
También ahí está el texto guía para que ustedes puedan eh cambiar en algunos apartados, eh van a encontrarse en con paréntesis donde ustedes van a poner el nombre de su producto, el nombre de ustedes, eh etcétera.
Speaker A
¿Cuál es la propuesta? Vamos a hacer un sistema de información web que centralice la gestión de las citas.
Speaker A
Por favor, antes de entregar reemplacen todo lo que está en paréntesis y borran solamente las instrucciones y los ejemplos. Este es el documento que ustedes se van a encontrar, ¿listo? Ese es el documento que yo les voy a
Speaker A
Listo, ya dijimos qué vamos a solucionar y qué vamos a plantear.
Speaker A
La plantilla, eso que dice plantilla guía a desarrollar, no le vamos a cambiar, solamente lo que está en amarillo en esta primera hoja.
Speaker A
¿Cuáles van a ser nuestros límites? Miren: en esta primera versión que se va a liberar no se van a hacer pagos en línea. Se estarán preguntando por qué pagos en línea. Recuerden que hay citas particulares, o si son por EPS se pagan cuotas moderadoras, copagos, entre otras. Toda esta información se levantó en el proceso de elicitación.
Speaker A
la fecha que lo elabora. Fecha de elaboración es diferente a la fecha de subida.
Speaker A
Entonces, el sistema de información lo vamos a hacer hasta esa parte, solamente agendamiento. Todo lo que tenga que ver con facturación, con pasarelas de pago en línea, no lo vamos a incluir. ¿Listo?
Speaker A
Entonces esto se lo van a encontrar ustedes en cada uno de los apartados. Entonces tenemos la la introducción, donde dice qué debe escribir.
Speaker A
Entonces, tenemos la necesidad, la propuesta y los límites. Esas son las tres bases que siempre debemos tener en cuenta y preguntarnos antes de iniciar la construcción de la evidencia.
Speaker A
Ejemplo, un centro de atención registra las citas manualmente y presenta dificultades para consultar la disponibilidad y el estado de las solicitudes. ¿Listo?
Speaker A
Vamos a construir la evidencia que ustedes van a entregar. ¿Cómo se organiza un SRS? Para los que se leyeron el material de formación superjuiciosos, observaron que en él nos hablan de un documento estipulado por la ISO/IEC/IEEE 29148, ¿cierto? Esa estructura no nos la inventamos, ya está establecida y tiene unos ítems. Si se fijan al lado izquierdo, está la tabla del material de formación.
Speaker A
Este es un texto guía. Pero la redacción de ustedes, yo la puse aquí en gris, esto es el ejemplo de cómo deben de redactar, ¿listo?
Speaker A
Ese material tiene una introducción, una descripción general del producto, los requerimientos específicos, entre otros.
Speaker A
apartados de color gris es el ejemplo de cómo deben de redactar. Y lo que está en amarillo con son las instrucciones de lo que debe ir.
Speaker A
A su derecha van a ver una estructura que dice "material de la tabla 6" y "nuestra plantilla".
Speaker A
O sea, ¿a qué se refiere? Okay, Tomás. Ya. Ah, y otra cosa, profe, que yo integral tú entregaste un proyecto Eh, profe, es que yo no sé por qué como que me dio como administrador o yo no sé,
Speaker A
Les voy a pasar un documento, una plantilla, donde ustedes van a diligenciar. Ya está estructurada, no le van a cambiar nada, solamente lo que aparezca en color amarillo y rojo, que ahorita se los muestro, es lo que van a modificar y plasmar allí su documento. La plantilla no me la vayan a alterar, por favor.
Speaker A
Eh, no es que esté de administrador. Esa, exacto, todos los que están en la sesión yo se los habilito a todos porque como yo estoy presentando no estoy pendiente Ah listo listo.
Speaker A
No, no vamos a inventar nada: vamos a seguir lo que dice el material y bajo la norma.
Speaker A
El proyecto integral es ustedes presentaron un proyecto de licitación, ¿sí? Yo les dije, piensen en el proyecto que van a hacer ustedes de aquí en adelante.
Speaker A
Hoy no vamos a detallar requisitos funcionales, eso es para la próxima sesión, ¿sí? En la plantilla vamos a hacer el proceso de cada uno de los puntos que tienen que desarrollar, tomando en cuenta el sistema de información de citas. Yo lo llamé CitaSalud, ¿sí? El problema que planteé es que hay muchas instituciones de salud que manejan la agenda y las historias clínicas en herramientas separadas o manuales. Entonces se pierden las citas, hay registros incompletos, errores al cobrar, etcétera.
Speaker A
proyecto integrador significa que usted de aquí en adelante todas las evidencias técnicas las va a trabajar sobre esa idea de negocio, sobre esa idea de emprendimiento, sobre ese proyecto productivo o simplemente con el proyecto para ah terminar su técnico, ¿listo?
Speaker A
Mi proceso parte de un agendamiento: el paciente solicita la cita, recepción la asigna, y cuando el paciente es atendido por el profesional, este hace la apertura de esa consulta, regis...
Speaker A
Ay, se me perdió. Entonces, aquí les presento con otros tips adicionales a los que van a encontrar en el documento que debe de ir en cada uno de los apartados.
Speaker A
Recuerden que a la introducción siempre presenta el problema, la solución y el contenido del documento.
Speaker A
Entonces, ustedes acá, entre dos y tres párrafos cortos, van a detallar la necesidad o problema, el nombre y la idea de la solución y qué contiene el SRS, ¿listo?
Speaker A
Espérenme un momentico, por favor. Listo. El propósito del documento es para qué se escribe el SRS y quién lo va a leer.
Speaker A
Entonces, en este apartado es qué debe escribir, para qué sirve el documento, quién lo usará y qué se hará con él.
Speaker A
Ojo, hablan del documento, mas no de la aplicación ¿listo? En el alcance, qué hará el producto y qué no hará.
Speaker A
Recuerden que aquí en alcance también tenemos en cuenta la limitación. Entonces, para quién es, qué necesidad atiende, sus capacidades generales y qué va a quedar por fuera de esta versión.
Speaker A
Un ejemplo, en este documento vamos a incluir programar y reprogramar y con y cancelar citas, registrar historias clínicas, facturar, reportar citas. ¿Qué no va a incluir? Ah, que no va a incluir urgencia hospitalización, no va a incluir teleconsulta, no va a incluir
Speaker A
pagos en línea, no va a incluir inventarios, no va a incluir auditoría de cuentas, ¿sí? Este es un ejemplo de qué va a incluir y qué no va a incluir, pero ustedes lo van a redactar en su documento. Y cuál es el documento que
Speaker A
les voy a pasar está muy detallado. El resumen del producto. Aquí, este es el apartado que más porcentaje tiene, chicos.
Speaker A
Esta es la sección que más pesa. Les va a ir un párrafo general de la solución y va a tener tres apartados.
Speaker A
El primer apartado se llama funcionales, entonces, ¿qué hace el producto? El segundo apartado, características de los usuarios, quién lo usa y cómo es. Y el tercero, las limitaciones.
Speaker A
Estamos viendo también las funciones generales del proyecto, es es otro apartado. Aquí se van a describir las grandes capacidades y se escriben en verbos irregulares y sin detalle. Entonces, por ejemplo, ¿qué son verbos irregulares? Los que terminan en ar, er, ir, ¿sí? Entonces, gestionar
Speaker A
citas, gestionar historia clínica, facturar servicios, administrar. Entonces, por ejemplo, en o en alguno de los de las aplicaciones que ustedes tienen, iniciar sesión o crear cuenta, registrar usuarios, sí, todos esos son las capacidades que va a tener el
Speaker A
sistema de información y se describen con verbos irregulares. Entonces, ustedes se preguntan, "Instructora, ¿yo cómo sé que va a ser mi sistema de información?" En este apartado, en el material de formación, hay una parte que llama descomposición funcional y partimos de
Speaker A
lo general a lo particular ¿si? donde van a encontrar esto en análisis de especificación de requisitos que yo les puse en el anuncio que debían de leer ese material entonces si yo voy desde lo general a lo particular
Speaker A
de lo general es vamos a hacer citas, vamos a programar citas, a cancelar las citas, a reprogramar si yo paso a otro nivel tenemos las historias clínicas ¿me permiten un momentico?
Speaker A
entonces tenemos otras gestiones que la historia clínica, la facturación y la administración de los pacientes esto lo vemos en cada uno de estos eh digamos bloques de este mapa de mapa conceptual, ¿si? en el en digamos rango de jerarquías
Speaker A
características de los usuarios aquí vamos a describir quién usa el sistema, para qué lo usa y qué necesita entonces un ejemplo, seguimos con el software de historia clínica y de agendamiento entonces quién lo usa, lo va a usar un
Speaker A
paciente ¿qué va a hacer el paciente? ¿para qué lo va a usar? para pedir la cita, para consultar, para reprogramar o cancelar la cita, ¿si?
Speaker A
¿qué nivel técnico va a tener? básico porque no va a tener mucha interacción. Eh necesidad es si los textos son legibles eh o a tener pocos pasos.
Speaker A
Las personas que hacen admisiones, entonces, van a registrar pacientes, ¿ustedes me están escuchando? Sí.
Speaker A
Okay. Sí. Las admisiones los los de admisiones van a registrar los pacientes, van a asignar la cita y van a registrar la llegada del del paciente, ¿cierto? ¿Qué nivel técnico requiere el requieren estas personas o estos que son admisionadores
Speaker A
de citas? Un nivel medio, ¿sí? ¿Por qué? Porque deben de ser rápidos para hacer las tareas repetitivas.
Speaker A
El profesional en salud, ¿qué va a hacer el profesional en salud o para qué va a usar el el sistema de información? Para ver su agenda y para registrar su historia clínica.
Speaker A
Necesita un nivel el técnico es de usuario, no necesito nivel técnico medio, pues porque tiene que al menos saber cómo abrir una aplicación, cómo cerrarla, ¿sí? Son cosas medias a básicos.
Speaker A
Si es web, si estamos hablando de web, entonces tiene que saber qué es un browser o navegador, ¿sí?
Speaker A
El facturador, ¿para qué necesita el facturador el sistema de información? Ah, pues para generar las facturas y los RIPS.
Speaker A
¿Cuál va a ser el nivel técnico? Medio, ¿sí? Todos, digamos, estas personas que más interactúan son medio.
Speaker A
Pero el administrador del sistema de información, sí, su nivel técnico es más avanzado, ¿sí? Porque él tiene que crear usuarios, tiene que crear permisos, tiene que crear servicios y tarifas y, obviamente, va a tener un desarrollo más grande en
Speaker A
el el de información. Entonces, por eso su nivel técnico deberá ser más avanzado. Entonces recuerden yo les pongo normalmente a ustedes como tips o fórmulas, aquí vamos a ver a a tener en cuenta, este usuario utilizará el producto para
Speaker A
¿para qué lo va a usar? ¿Qué actividad va a ejercer? Y qué requiere, conocimientos son necesidades. Entonces, un nivel técnico básico o requiere manejo, no sé si algunos tengan algún sistema de información, eh manejo en en en en Moodle, manejo en ofimática, no
Speaker A
sé, dependiendo pues de lo que ustedes van a desarrollar en cada uno de sus proyectos.
Speaker A
Las limitaciones del producto. Estas limitaciones, aquí se tienen en cuenta las condiciones externas que pueden limitar el uso. Como, por ejemplo, la conectividad. Si yo estoy diciendo que es un sistema de información web, pues yo tengo que garantizar
Speaker A
conectividad a los usuarios. Entonces, si no hay internet, pues obviamente no se va a poder agendar, no se va a poder registrar la historia clínica. Entonces, esto es una limitación del producto que es externa, pero no lo puedo dejar pasar
Speaker A
por alto. En temas de normativa, recuerden que en este caso, pues hay normas que la 1581, la de los de eh la de ay, acceso a datos personales, eh la resolución 1733, que es la de las historias clínicas, entre otros.
Speaker A
Eh terceros, pues si se hay fac si hay facturación electrónica, si se va a conectar a la DIAN, si vamos a generar RIPS directamente en el Ministerio, o sea, hay que embarcar a perdón, hay que abarcar todas esas
Speaker A
esas condiciones externas. Recursos. Mmm, que digamos que no tengan equipos de cómputo, ¿sí? Que se les dañó de pronto los dispositivos, entonces hay que tener allí en cuenta esto.
Speaker A
En el tercer apartado dice interfaces externas. Entonces, ¿cómo se conecta con personas, sistemas y equipos?
Speaker A
Aquí las interfaces no las vamos a desarrollar como un prototipado, sino que las vamos a dejar establecidas en una en una tabla muy parecida a esta.
Speaker A
Entonces, el usuario en la aplicación que ustedes van a desarrollar, que la mía se llama City Salud, es una web en computador, tableta y celular, portal de pacientes y módulos por rol.
Speaker A
¿Para qué? Para que cada usuario haga sus tareas, ¿sí? Es es como imaginarse Aquí ustedes van a imaginar cómo va a ser esa interfaz gráfica, donde cada uno de los usuarios va a interactuar, ¿listo?
Speaker A
Tanto externas como internas. Los requisitos de usabilidad, esto es muy importante. La usabilidad es lo que uno más mira en un sistema de información.
Speaker A
La idea de un sistema de información es que sea fácil, entendible, que no sea mmm visualmente agresivo, que se pueda aprender, que se pueda usar sin tanta ayuda, que no tenga que estar interactuando con tantos botones, ¿sí?
Speaker A
Y que pues obviamente cuando dice que se pueda medir es que se pueda medir en tiempo.
Speaker A
Que el aprendizaje sea rápido, que la navegación sea clara, que sea legible, no que vamos a poner un fondo verde fluorescente y letra amarilla porque pues eso no se va a ver, ¿sí? A eso hablamos de legibilidad también. Que sea consistente con lo que
Speaker A
lo que estamos viendo gráficamente sea consistente con lo que se va a hacer. Entonces, yo no puedo hablar de historias clínicas y hacer un fondo de unas tortas con bombas, no tiene sentido, ¿sí? No es consistente. Y que
Speaker A
los mensajes sean claros. ¿Qué se refiere con los mensajes sean claros? Pues cuando uno hace una acción exitosa, a uno le dicen, ejemplo, eh su cita ha sido agendada correctamente. Eso es un mensaje claro.
Speaker A
No es lo mismo decir su cita ha sido agendada correctamente a decir guardado. No es claro para el paciente. ¿Qué guardó? ¿Guardó la cita? ¿Qué guardó?
Speaker A
¿Sí? Eh si es una un mensaje de excepción o de o de error, eh el registro eh no no fue almacenado o le falta un campo tal X campo para diligenciar, ¿sí? Todo lo hemos vivido en algún momento cuando
Speaker A
hemos diligenciado formatos o hemos hecho registros web. A eso se refieren con mensajes claros. Eso se llaman ventanas emergentes emergentes o mensajes pop up, que son las ventanitas que uno le salen allí de que eh registro exitoso, eh por favor, ingresa tu
Speaker A
dirección, ¿sí? Es todos esos mensajitos. Que se vea bien, que la letra sea legible.
Speaker A
Vuelvo y les digo que te que no sean con tan contaminados visualmente. Y pues lo más importante que sea muy intuitivo también para el usuario.
Speaker A
Restricciones del diseño. Aquí son las reglas obligatorias. Cada una con su origen. Entonces, por ejemplo, comenzamos hablando de datos de de datos personales, siempre siempre, cualquier sistema de información que vaya a hacer uso de datos personales, la res la regla
Speaker A
obligatoria es la ley 1581 del 2012, que es la autorización de manejo de datos de de mane manejo de datos personales. Para el sector salud, para el sector financiero, para cualquier sector, ¿sí?
Speaker A
Entonces, en reglas obligatorias, aquí va a ir las resoluciones, reglas o eh decretos que ustedes tengan que tener en cuenta para el desarrollo de su sistema, ¿sí?
Speaker A
El último punto son las referencias. Ojo aquí, chicos, que en el documento, en el entregable anterior, hubo mucho problema con esto y yo les hice mucho hincapié con el tema de la bibliografía.
Speaker A
Aquí no vamos a llenar por llenar, solamente lo que ustedes consultaron y que se Ay, acá me equivoqué, y que se pueda verificar.
Speaker A
Si ustedes citan algo, es porque yo al darle clic y y recuerden que todos los documentos son con APA, y yo al darle clic voy a ir a buscar y y que ese apartado que ustedes están allí referenciando sea lo que yo encuentre
Speaker A
realmente en ese enlace o en ese ítem de bibliografía que colocaron. Si se se apoyaron con la guía, recuerden, por favor, coloquen el prompt completo. Mmm, muchos entregaron el prompt, pero solamente el inicio. Y si yo pongo ese
Speaker A
prompt, y si yo lo reviso, pues obviamente no me va a dar todo lo el bosquejo que ustedes hicieron. Entonces, pongan el prompt completo, que es eso no les quita puntos.
Speaker A
¿Listo? Entonces, esto es lo que ustedes van a a encontrarse en el documento. ¿Qué deben entregar?
Speaker A
Ese es el documento. Acá ya están cada uno de los apartados, está la la desde el apartado dos, tres cuatro.
Speaker A
Ah, bueno, va hasta el seis, va hasta el cinco perdón. Y si ustedes observan, acá están las tablitas que les hablaba, ¿sí? Cada uno de los puntos, mis estimados aprendices, trae la la explicación, un ejemplo de redacción que es son estas
Speaker A
lo que está en gris. Ustedes pueden y redactarlo, usar las mismas tablas, pero con la información del sistema de información que ustedes van a realizar. No no copien y dejen lo que está allí.
Speaker A
Es cópienlo, úsenlo, pero ajústenlo al sistema de información de ustedes, ¿sí? Porque eso también noté que se estaban como, no sé si se rotaron o cogieron eh trabajos de eh grupos anteriores y ni siquiera cambian el nombre de ustedes, ni siquiera el número
Speaker A
de la ficha, ni siquiera el año. Estamos en 2026 y trabajos de 2025, 2024, entonces, por favor, pues también hay que leer un poquito, muchachos.
Speaker A
Entonces, antes de de subir la evidencia, ustedes van a validar estos puntos, que el documento corresponde al proyecto integral de ustedes, que es justamente lo que les estoy diciendo.
Speaker A
No puede ser que yo esté hablando de una historia clínica y por allá entregue o otro un o por ejemplo, la app de turismo.
Speaker A
No tienen que ser coherente con lo que ustedes ya están desarrollando, que sea lo mismo, que sea de ustedes. Tomen al menos el tiempo de eso.
Speaker A
Que el propósito explica de manera detallada para qué se va a elaborar el SRS.
Speaker A
Que el alcance describe qué incluye y qué excluye el producto. El resumen presenta funciones generales, usuarios y limitaciones.
Speaker A
Las interfaces externas están descritas o se justifica que no aplica. Los requisitos de usabilidad son claros y pertinentes. Las restricciones corresponden a condiciones reales del proyecto.
Speaker A
Las referencias son verificables y siguen el formato solicitado. Ojo, este donde dice referencias es todo lo que tiene que ver con bibliografía.
Speaker A
Y muy importante, que también puse algunas observaciones. Chicos, nosotros trabajamos con una herramienta que se llama Ofimática.
Speaker A
Por favor, configúrenla, organicen el tema de la ortografía. No puede ser que me entreguen trabajos con problemas de ortografía. Si no si no están seguros, cópienlo y pásenlo por la IA que, por favor, le validen la ortografía, la redacción. Si ustedes
Speaker A
están enumerando, pues sigan la secuencia, 1 2 3 hasta el número que sea, no 1 2 6 u 8.
Speaker A
¿Sí? La presentación del documento, ya les dije, es una plantilla, no la alteren. Reemplacen todos los textos que están en paréntesis del documento base que les voy a entregar. Eliminen los ejemplos e instrucciones y dejen solamente el pedacito de ustedes. ¿Listo?
Speaker A
¿Qué es lo que van a eliminar? Me voy a devolver un momentico. Van a eliminar lo que está en color amarillo con letra roja y lo que está con gris y ustedes donde dice, redacte aquí, es donde ustedes van a redactar la
Speaker A
parte de ustedes. No me vayan a entregar documentos así como se los estoy entregando.
Speaker A
¿Sí? Por favor. Listo entonces Eh Hay seis errores que que van a restar puntos.
Speaker A
Copiar el ejemplo y que no sea el proyecto de ustedes. Funciones con detalles, que no tenga esas funciones y lo detalles.
Speaker A
Que el propósito de la no esté en el documento. Mmm, la usabilidad con no no sea clara, con números y condiciones.
Speaker A
El alcance no tenga Que no incluye Restricción Listo, es decir, la limitación. Para esta entrega hay un por De evaluación de los siete puntos. El documento tiene siete puntos.
Speaker A
Presentación y propósito equivale al 5%, alcan El producto 10%. El más importante es el resumen del producto. Recuerden que aquí se van a ver apartados que equivale al 40%.
Speaker A
Inter interfaces externas el 10%. Requisitos de usabilidad y restricciones del diseño 15% cada uno. Y las referencias con el pronteia el 5%.
Speaker A
Entonces, esto es lo que ustedes van a entregar. ¿Dónde lo van a entregar? En el en la plataforma Sayuna, que dice taller de instrumentos de especificación.
Speaker A
Aquí vamos a subir ese documento, ¿sí? ¿Cómo lo vamos a entregar? Por favor, en PDF, ¿listo? ¿Hasta cuándo? Hasta el domingo 1º de noviembre.
Speaker A
Ya les comparto el documento por eh Por el grupo y también se lo subo a la plataforma.
Speaker A
¿Preguntas hasta acá? ¿Ha sido claro? Voy a detener la grabación para poder subir la sesión.
Topics:SRSespecificación de requisitosISO/IEC/IEEE 29148ingeniería de softwareagendamiento de citaselicitaciónhistorias de usuariorequisitos funcionalesSENAdocumentación de software
