Ingeniería de Requerimientos Definición y Proceso

Transcripción generada automáticamente de FI-7669-Fundamentos de Ingeniería SF-77901-AN_ N3A0826 _FIS 14-0.mp3.

Resumen

La sesión introduce el concepto de requerimiento como especificación de lo que se debe implementar en un sistema, abarcando tanto funcionalidades como restricciones sobre el proceso de desarrollo. Se distingue entre el dominio del problema (donde se identifican necesidades a partir del contexto del cliente) y el dominio de la solución (donde esas necesidades se traducen en requerimientos técnicos). Se presentan cuatro perspectivas: funcionalidades, restricciones de dominio, restricciones de calidad y reglas de negocio, diferenciando que las reglas de negocio las define la propia empresa mientras que las restricciones de dominio provienen del contexto externo (por ejemplo, legislación). Se analizan problemas frecuentes: objetivos y alcance mal definidos, comunicación centrada en la interfaz y no en las tareas del usuario, requerimientos ambiguos, scope creep, gold plating y falta de consideración de los afectados. Se enfatiza el alto costo del retrabajo (30-50% del desarrollo) y que el 45% de los errores provienen de mala especificación. Se introduce el proceso de ingeniería de requerimientos con sus actividades: elicitación, especificación, documentación y validación, destacando que validar un requerimiento es mucho más barato que corregir el sistema ya construido. Finalmente, se clasifican los requerimientos en funcionales (qué hace el sistema) y no funcionales (cómo lo hace), con ejemplos y una anécdota sobre performance que ilustra cómo omitir un no funcional genera retrabajo.

Puntos clave

Un requerimiento es una especificación de lo que se debe implementar: funcionalidades, propiedades, atributos o restricciones del proceso de desarrollo.
Se distingue entre dominio del problema (necesidades relevadas del contexto) y dominio de la solución (requerimientos técnicos derivados).
Cuatro perspectivas: funcionalidades, restricciones de dominio, restricciones de calidad y reglas de negocio.
Las reglas de negocio las define la empresa; las restricciones de dominio provienen del contexto externo (leyes, regulaciones).
Problemas comunes: alcance mal definido, ambigüedad, scope creep, gold plating, comunicación centrada solo en la UI y falta de validación con el cliente.
El retrabajo consume 30-50% del costo de desarrollo y el 45% de los errores se deben a mala o poca especificación de requerimientos.
El proceso de ingeniería de requerimientos incluye elicitación, especificación, documentación y validación.
Los requerimientos se clasifican en funcionales (qué hace el sistema) y no funcionales (cómo lo hace); ambos son igualmente importantes.

Transcripción

¿Cuál esQué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué?o matar? Como un… o sea, un par de… Está perfecto, pero dame un ejemplo de un requerimiento. -Dentro de la dinámica. -Que la foto perfil está en un centrado. Ok, perfecto. Ok. En remoto, ¿quién da otra cosa? Que hayan tres contadores, que se organizen las películas o las series en filas. Ahí va. Saben que hay un detalle que nadie se dio cuenta y que oese un requerimiento bastante… Que el formato sea…buonista. A ver si te cuento, mira. No, no. Pero fíjense que las películas estaban mordenas alfabéticamente. Ah, eran películas. Sí. Y ojo, que eso al final le ponen necesidad y es algo que se tiene que cumplir también. Pero bueno, no importa. ¿Qué? ¿Qué queremos transmitir con esto? Fíjense que me importó que ustedes trabajaran al Apis y que ellos trabajaran con una herramienta para hacer mock-ups. Al final los dos tuvieron su desencuentro con la referencia original por el tema de cómo se transmitía y el contexto en el que se transmitía lo que se quería hacer, ¿cierto? Entonces, esto es lo que vamos a tratar de estudiar ahora. ¿Cómo transmitir esto de forma tal de que haya menos espacio de interpretación y todo sepamos lo que realmente tiene que suceder al momento de construir eso? Muy bien. Esto no es lo que puedes. No. Vamos a hablar de requerimiento, su definición, perspectiva, problemas relacionados, ingeniería de requerimiento y ya cómo proceso, la clasificación y buenas prácticas. Entonces, requerimiento como tal, una especificación de lo que se debe implementar. ¿Qué tanto le especificarán ustedes? Pasen dibujito, ya eso es otra cosa. Fíjate que la más de una descripción de cómo se debe comportar el sistema o de una propiedad o atributo del sistema pueden ser restricciones sobre el proceso de desarrollo. Esto es cristiano que es. No solamente estamos hablando de que hacer el sistema sino también de cómo lo hace. Y eso va a ser particularmente interesante cuando empecemos a hablar del concepto de calidad. Ok. Entonces ¿Qué pasa? Vamos a partir de problemas y necesidades para llevarlos a requerimiento. Cuando estamos construyendo software, estamos en estas etapas, hay dos dominios principales. El dominio del problema y el dominio de la solución. ¿Por qué no? Resulta pertinente esto. Porque al final nosotros relevamos requerimientos de problemas que viven en un contexto. No nos inventamos los problemas. Ojo. Y eso es algo que va a ser particularmente interesante cuando estemos trabajando en el obligatorio. Porque nosotros lo que les vamos a evaluar es que detecten problemas que existen para traducirlos en requerimientos y poder implementar una solución. No que ustedes digan "bueno, vamos a hacer esto, esto, esto y esto y esto porque pintó". No. Tiene que haber un problema que se esté soltuntando de eso y para que ustedes van a hacer una relevasión que solo vamos a ver. Llenarnos a palabras más técnicas y… fancijaistema, eso. Lo vamos a profundizar más tarde, pero tengan en cuenta que los requerimientos no solamente van a estar casados con necesidades de clientes, sino en ciertas cosas que se tienen que cumplir y eso es a lo que nos referimos con restricciones. Ahora, desde que perspectiva se pueden ver los requerimientos. Se pueden utilizar distintas perspectivas y son funcionalidades, restricciones del dominio, restricciones de calidad y reglas del negocio. Vamos a ver un poco qué significa esto. Funcionalidades supongo que pueden llegar a ser un poco más intuitivo, ¿no? Son las capacidades relacionadas que proven valor al usuario y son descritas como un conjunto de requisitos funcionales. Define lo que el sistema hará. Entonces, en el ejemplo del mock-up que estaban haciendo ustedes, bueno, capaz de registrar una película como vista, es un requisito funcional, ¿tá? Es una funcionalidad. ¿Por qué? Porque la aporta valor al usuario porque ya no se tiene que acordar cuál película ha visto porque las puede guardar y las puede consultar cuando quieren. Luego tenemos las restricciones de calidad que ya no nos hablan tanto del que hace el sistema sino del cómo. Y porque Y por qué esto nos habla de calidad? Porque básicamente son esos puntos de vista que le van a dar valor competitivo con respecto a otros productos. ¿Por qué? Nosotros podemos tener digamos dos plataformas bancarias. Pero si una ameacera transacción en microsegundos y los los tres estarán minuto cargando, que es lo que es lo que es lo que es ¿Tenemos restricciones del dominio, lo leemos. Son las limitaciones impuestas por el dominio del problema, es decir, por el contexto en el que se aplica el sistema. Y regla de negocio es una política guía estándar que, de fin, nos restringe algún aspecto del negocio. Habla de cómo funciona el negocio. Entonces, si leemos que estas dos definiciones, ¿para ustedes cuál es la diferencia entre amas? Si quieres la ley, otra vez. Lo que yo comento es que la regla es… Seguramente lo que hacen es saber fruta, no importa, perdón, mi algo. El niño de lo que barca y el rey de la demostración que… No sé, no me salió, como pica el rey de la barca. Ah, interesante. A ver, ya dar un ejemplo. Tenemos un sistema en el que registramos las calificaciones, ¿verdad? Y este sistema registrar las calificaciones al cerrar el periodo académico, sea trimestre, semestre, año, lo que fuese nos hace una sumatoria y determina si el estudiante aprobó o reprobó, ¿sí o no? ¿Qué pasa? En Venezuela las calificaciones son sobre 20, no son sobre 12, entonces que pasa que las reglas de negocio para el sistema en el que se manejan, exactamente, en el que se manejan las calificaciones en Venezuela, se dejen por reglas de negocio distintas a las de acá, ¿por qué? porque la regla de negocio es, si la nota es mayor o igual a 10, el estudiante aprobó. Pero acá no necesitas 10, necesitas otro número para probarlo. Esa es la regla de negocio. Entonces, aunque son sistemas parecidos, las reglas de negocio terminen un comportamiento diferente. Lo mismo puede pasar por, con cál de IVA que no necesariamente IVA va a ser el mismo porcentaje o el mismo número en todos lados etcétera, etcétera ¿Qué otro ejemplo se le ocurre de eso? si no vamos a ver el obligatorio por ejemplo si ustedes ya saben el dominio del problema y vamos a ver de qué va ¿Qué regles de negocio se les ocurriría? Ok. De lo obligatorio. Ajá. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, Bueno. y dependiendo de esto les conviene tipo bueno se come de tal forma pero en lo mismo van a comer a un lugar que ya sé. Ok, entonces me está diciendo que de pronto la regla de negocio es que las actividades tienen que mostrar por categoría. Exacto. Perfecto. ¿Qué otra cosa podría hacer? Es una necesidad. No, es algo que te tienes que sujetar. Después va a haber una funcionalidad asociada a esa regla de negocio. Ok. Sí. es una ¿Cómo están las que ya pasaron? Eso es una regla de negocio. ¿Qué es una restricción del dominio? Fíjense que las reglas del negocio tienen la particularidad de que hablan de algo que tiene el comportamiento desde la interna. En cambio, las restricciones del dominio vienen de afuera, vienen del contexto. Y de hecho, tener este tipo de cosas presentes es importante. Y les veo un ejemplo de por qué es importante. ¿Qué pasa acá? El Osmo reponde a la multa de 120 millones de euros del agua con más transparencia en X. ¿Qué pasó acá? La sanción impuesta en diciembre de 2025 se convirtió en la primera gran muerte de Bruselas en la plataforma bajo la ley de servicios digital. ¿Qué pasó acá? Que esta funcionando de una manera super tranquila. Pero lo que era el enero europea hubo un tema de, bueno, no estamos siguiendo estándares de transparencia con el tema de la y a nivel de código ni de que un programador fuera bueno fuera malos, decisiones que se tomaron a nivel negocio no contemplaron el dominio de la legislación de servicios digitales de otros lugares y resulta que eso era un problema. Entonces, ¿por qué no es una regla de negocio? Porque eso no lo definió ex, sino que es algo que se tiene que someter día fuera. Entonces, ¿cuál es la moral de Jade hecha de él cuál es la principal diferencia entre una regla de negocio y una restricción del dominio la regla de negocio la define la propia empresa y la restricción del dominio es algo que se tiene que sujetar por ejemplo podría un caso yendo a esto como medio dado pero tipo que no le pueda presentar a ciertos eventos a menores de 18. Claro, correcto. Es una reaccion de dominio. Sí, es correcto. Porque ya no es algo que defines tú como alguien que quiere mostrar actividades, es que si le muestras a un menor algo, para que compre alcohol. No, no es good, no es good. Bueno, hasta acá preguntas. Intervenciones, sugerencias. Ganas de irse, no se vayan por. Bueno, muy bien. Qué problemas se pueden relacionar al momento de trabajar con requerimientos. Objetivos, visión y alcance al proyecto que no fueron claramente definidos. Y qué pasa con esto? que las por un interfaz pues más se va a perder al momento el tema de la documentación, en el tema de la documentación y ahora en este tema del agilismo nos apoyamos mucho también en las personas y en su colaboración porque somos un equipo multidisciplinario, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla el cliente dice "Me paro, estoy ocupado, no sé, resolverlo, por eso te pago". Y eso puede ser un problema, porque si no tenemos esa colaboración, entonces nosotros vamos a empezar a interpretar. Y ya dijimos que el tema de la interpretación puede ser un problema. Esto va a dar un poquito de la mano, el equipo de desarrollo no puede interactuar directamente con los usuarios para entender sus necesidades. Los desarrolladores encontraron ambigüedades e información faltante al momento de codificar. ¿Y qué pasa? Que una cosa es darse cuenta de que algo está vivo. Conversándolo antes de empezar a trabajar y otra cosa no te cuenta cuando te metiste códigoetista de código. Entre más código generaste, más caro te vas a salir tratar de render esto después. La comunicación entre interesados se centró en la interfaz de usuario, no en lo que los usuarios necesitaban para realizar sus tareas. Ah, es que se ve divina, pero no sabemos si realmente es lo que necesitamos, no, pero se ve divina. Entonces, vamos a hacerla así. Los clientes nunca probaron los requerimientos. Eso también puede ser un problema. Ahora, este es básicamente un poco lo que pasó con el tema de la dinámica del inicio. Fíjense que esta imagen tiene mucho tiempo de vida. O sea, a mí me mostraron esta imagen cuando yo estudié. Ya en otra materia no la dan mucho. Esto se lo dejo para que lo revisen después, pero es básicamente una anécdota de cómo el no tener claro los alcances y las necesidades bien previstas, un proyecto puede llegar a ser fracasado. Pero esto lo revisen después, no lo vamos a ver ahora. Entonces, puntualizando el problema que podemos tener a momento a la hora de requerimientos, tenemos el crecimiento y cambio en los requerimientos. Que, ojo, esto es natural que suceda. O sea, es un problema, pero es esperable que suceda. Porque para eso existe el agilismo y porque entendimos que nuestro entorno es cambiante y más ahora que todo cambia cada cinco segundos. ¿Verdad? Pero también tenemos el scope creep que es la corrupción del alcance que pasa que una cosa que yo le había dado a lucas y a julieta el dibujito que teníamos y tan comprometimos que en 10 minutos y vamos a hacer la dinámica verdad pero si al pasar cinco minutos y le pasaba y este y este y este y este y le metía 7 formularios más Bueno capaz que yo me comprometí en hacer la dinámica en 10 minutos Pero es serante que me clavara los otros 7 formularios, sataac, no puede ser Esto sucede y después nos quejamos de que las cosas no salen a tiempo pero bueno, porque será Luego tenemos el "book plotting" que es agregar cosas que realmente no portan valor, pero bueno, como ya estamos, entonces no importa, agrégalo porque es fácil. Es un vicio que se tiene, es algo que sucede mucho y es una mala práctica al final del día, sobre todo porque visita nuestras métricas y se supone que las métricas son algo que usamos para medir el éxito que tenemos como un proyecto, pero bueno, son cosas que pasan. que Y claro, como el desafío ahí es aportar valor y resolver problemas, el no considerar a las personas afectadas por ese sistema es como "¿Quiero resolver problemas?" pero no me estoy haciendo la pregunta de quiénes son las personas que padecen esos problemas. Y el ímputo de esas personas es muy valioso el momento de definir requerimientos. Entonces, ¿qué sabemos del levantamiento de requerimientos con la evidencia empírica hasta ahora? El impacto de los errores en requerimientos se resume como retrabajo y nadie quede a hacer retrabajo, es lo más frustrante que hay. Distinto investigadores ha presentado evidencia empírica sobre el impacto. El de trabajo consume del 30-50% del costo total de desarrollo y los errores son ¿Qué puede pasar en? ¿Qué pasa acá? Que acá ustedes son sus peores enemigos. ¿Por qué? ¿Por qué esos requerimientos los van a definir ustedes? O sea, los requerimientos que ustedes van a implementar los van a definir ustedes. Entonces, hay un punto en el semestre que es muy gracioso porque ustedes definen los requerimientos a, b y c. Y después nos llega un mensaje por Timz de la nada y dice "Profes, para este requerimiento tenemos que hacer esto". Pero si lo definieron ustedes, ¿por qué ellos sabría eso y ustedes no? Es la pregunta ¿Qué es lo que puede pasar para que ustedes se vayan a la necesidad de hacerme esa pregunta? Tenemos requerimientos ambiguos Que cuando pasaron por el papel y pasó bien el pdf a gestión, hermoso Pero después lo vamos a agarrar porque tenemos que programar no se entiende y nada entonces haganse el favor a ustedes mismos de especificar bien los requerimientos tengo obligatorios y un detalle importante que no quiero que pierdan de vista en el primero obligatorio yo no quiero que ustedes sean mesquinos con los requerimientos te ¿Te destina en el requerimiento? O sea, mil si quieren, no pasa nada. No es la expectativa de nosotros que implementen todo lo que especifica. O sea, de hecho, parte de la no va a pasar nada malo ahí. Bueno, esto nos sigue hablando de cómo el retrabajo hace que se gaste mucha plata que no queremos gastar. Pero este número es importante porque el 45 por ciento de los errores detectados son por mala o poca especificación de requerimientos. Yo sé qué, qué pesado profe es lunes de noche, basta, basta, basta. Bueno, empecé con una dinámica, yo lo intente. Pero que pasa? y que al final ustedes vean a la calle se encuentran que sigue pasando. O sea, es graciosísimo. Lo que yo puedo tratar de prever es que esto les pase en el obligatorio. Es lo que les puedo tratar de que no les use a ustedes. Especialmente, o sea, cuando me llegas a explicarle al querimiento, recuerden que eso es por ustedes. Es lo que les puedo decir. Dato lo menor y también bastante evidente. Entre más temprano nos vemos cuenta de los problemas con los requisitos, más fácil lo hacer remediarlo. Entonces, ¿cómo reducir los errores? El primer punto es buenísimo, cometer menos errores. Jamás lo quiero venir, pero no importa, aquí estoy yo para mostrarles. Pero, ¿cómo se hace esto? Dedicar más tiempo a la tomar requisitos. ¿Qué es esto que se hacen las metodologíasologías tradicionales en las que les comento el sustento era la documentación dura y pura ahora en términos maságiles y en la formela que la industria trata de abordar estos temas es detectar antes los errores es decir bueno pero qué va a haber errores o sea ya está ab Abracémoslo, pensemos cómo mitigar ese daño. Y es básicamente, vamos a tratar de detectarlos antes, que no va a salir más barato, por lo menos. Y por eso hablamos del "Chief Left Testing". Entonces, ¿qué ocurría, por lo menos, en Warfield, cascado? esto de los gestradicionales, que había un esfuerzo tremendo en el proceso de requerimientos y después mientras estaban las otras etapas en cascada, bueno esto me enguado, y a diferencia de los procesos sáhiles, iterativos incrementales, es algo que va subiendo y bajando, subiendo y bajando por la misma naturaleza iterativa. Tiiing. Pregunta, antes de seguir con lo demás, ¿qué es un requerimiento? Puedes repetir la pregunta profe? ¿Qué es un requerimiento? Es una especificación de algo que vas a implementarlo, ¿no? Ahí va, sí, muy bien. Está, vamos a ello. ¿Ustedes se acuerda de esto? a ver no,Portese acuerdan de un esquema? De un esquema que les mostré el inicio que era un Powerpoint, que tiró una carita feliz, no se le suena. ¿Y qué es ese esquema de la carita feliz. ¿Está? Aquí teníamos un rectángulo principal. Era el proceso de infremieris. ¿Vverdad? Y acá teníamos. Recuerimientos. Recuerimientos. Y aquí entre 40 y si lo voy a poner ingeniería de requerimiento. ¿Qué pasa? Nosotros ahora, en lo que va de clase, hablamos de los requerimiento. Entonces, recién ahora vamos a hablar de un proceso. ¿Se entiende? Ahora vamos a hablar de un proceso. No habíamos hablado de un proceso todavía. Habíamos hablado de un artefacto y de una descripción. Ahora sí especificación de un requerimiento. OK. Ya es como está procesado el caso de uso en requerimiento. Claro, porque en realidad tú no puedes puntualizar un caso de uso sin saber de qué requerimiento parte. Claro. Sí, por lo menos el requerimiento, cuál puede ser el requerimiento? El sistema debe permitir mostrar reportes de ventas. Entonces, un caso de uso es un usuario de tipo administrador puede consultar el informe. En el otro caso de uso, imprime el informe. En el otro caso de uso, descara el informe y así, etcétera, etcétera, etcétera, pero fíjate que parte del requerimiento de generar los reportes. Entonces proceso de ingeniería de requerimiento. ¿Qué busquete proceso? ¿Traducir las necesidades de clientes y usuarios en requerimientos técnicos para implementar? Ahora le hago una pregunta. ¿Cuál sería la diferencia entre una necesidad y un requerimiento? Ah, algo de pensar. ¿Cuál sería la diferencia entre una necesidad y un requerimiento? Si lo necesito, el programa funciona y si lo requiere puede ser que sigan dando. Ajá, vamos a tener eso ahí. Quién da más? Que el requerimiento tiene que tener medido que es lo que se necesita para que cumpla o sea tipo algún definición de definición of dan, no sé cómo decirlo. Ok. ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? ¿Qué? tenemos ah que pena ahí dominio del problema de menos tenemos el dominio de la solución yo sé que solución lleva dentro chico ahí está tenemos dominio del problema y tenemos dominio de la solución. ¿Qué dudan? Se me quiso. Bueno, no importa. Las necesidades van acá. Y los requisitos. la palabra requisito y requerimiento pero otros no eh pero por las dudas y según esos otros autoras esto compienza o sea ni siquiera lo tienen que recordar pero dato de color esos autores colocan la palabra requerimiento en el dominio del problema y requisito en solución pero nosotros vamos a trabajar con requisito requerimiento como dominio la solución y necesidades en el dominio del problema. Juli, te voy a dar una pregunta. ¿Cuál es la diferencia entre una necesidad y un requisito? ¿Y un qué? Requisito o requerimiento. Requisito los o sea los trabajos definiendo en que esa lo que sí o sí tiene que tener, no necesidades a lo que les que tenga. No, necesitas. Necesitas que te ¿Pero qué es lo requerimiento? Si tengo medio naranja como un y los requisitos o requerimientos son las cosas que describen el que y cómo hace el sistema. ¿Sí? Entonces, ¿qué pasa? ¿Qué no toma las necunidades? Sí, dígame. Las necesidades surgen hablando de un cliente y el requerimiento surgiría programando ya, ¿no? Ay, casi. Pero bueno, pues te ayudo, no importa. ¿Cómo lo ajustamos para que quede perfecto ahí? Las necesidades las identificamos al relevar información del dominio del problema y los requerimientos los definimos al procesar esas necesidades en característica que va a definir el que o el como se va a comportar el sistema ¿Qué pasa? que no todas las necesidades. Le dio como el anaz. En la hora. No todos los problemas que identifiquemos en el dominio lo vamos a poder resolver nosotros con el sistema. Eso también es importante saberlo. ¿Por qué? Porque supongan que están con un tema de un sistema de ventas. ¿Está? Y entrevistando la persona, esta persona les dice, es que lo que pasa es que los vendedores no salen a vender. Y el sistema no va a salir a vender por yo tampoco. O sea, le puedo ayudar, les puedo dar herramientas, pero no puedes… Ese problema no lo puedes solventar, necesitas la contugente, no sé. no Si nos vamos a este tipo de ejemplo, ¿cuál podría ser el ejemplo de una necesidad? La verdad es que yo necesito una aplicación que me ayude a controlar mis gastos. Porque qué pasa? O sea, estás todo bien, o sea, yo lo quiero hacer porque quiero tener un mejor control de mis finanzas. Pero es que, claro, mi contexto, mi mi desenvolvimiento es que si yo estoy tomando un café con mi imposo, que opa la factura, la guardo, no, o sea me aburre, es un problema para mí eso pero no queda registrado en ningún lado. Ah, ta. O sea tu problema entonces es de accesibilidad al momento de querer registrar esas transacciones porque en tu diaria te genera fricción capaz que si puedo buscar una tecnología que te ayude a estar que te puede ofrecer te puede ofrecer una aplicación en la que no tienes que que no tienes que tipearlo sino que le manda una nota de voz y le dice a 400 pesos en cafetería culto con tal y que eso lo procesa y me lo dejen una base de datos con etiquetas cosas porque eso ella se dan cuenta que el problema tiene que ver en cómo una persona que va a pasar a ser nuestro usuario conv convive con un contexto y como una tecnología, le va a ayudar a que esa fricción diminuye. Esa es la diferencia entre un problema o necesidad y un requerimiento. El problema es ni fricción al momento de querer registrar castos y el requerimiento va a ser registrar datos e registrar transacciones a través de un audio. ¿Queda claro? Perfecto, muy bien. Entonces si volvemos a la diapositiva, es el proceso para introducir necesidades de clientes y usuarios en requerimientos técnicos para implementar. Y ya les di el ejemplo de eso básicamente. Objetivos, comprender y anunciar el problema. Chicos, esto no es fácil y esto lo tienen que hacer. Ya les aviso. Es un buen uso de la idea este. También les digo. Les voy a decirle la ella no se llama el problema son más bares que eso pero si está bueno que a ustedes interactor con cierto dominio identifiquen cosas y le digan a ella tengo estos conceptos procesámenos es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es ¿Qué es el problema? Exactamente. Y fíjate que ahí dice que le estamos hablando de si está bien o mal hecho. Estamos hablando de que lo que se hizo sirva para lo que tiene que servir. Ojo al dato. Muy bien. Entonces como todo proceso tiene sus actividades. Ya casi nos vamos chicos. Dos. Perfecto. No se les escapa una, chicos. Al elicitar, vamos a obtener información de la información que se le hace. 2 cosas que es lo más importante y cómo lo modelo. Después ve una parte que es mi favorita que es especificar que es cuando ustedes mismos caban su propia tumba, es divertidísimo. Pero documentar esos requerimientos y prototipos para saber qué tan específico lo vamos a tener y validar para saber si realmente eso nos va a servir. Si hay gente que aquí estamos hablando de requerimientos todavía y en mi conversación con Luca estamos hablando de validar el producto, pero acá ni siquiera tenemos que tener el producto hecho, aquí vamos a validar el requerimiento. ¿Por qué? Porque con la gráfica que vimos antes nos dimos cuenta que sale mucho más barato, vale, un requerimiento que valía el sistema ya hecho. Bueno, pero si hay algo con que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es lo que es término bastante importante que son las partes interesadas. Sabemos qué es eso. En un proyecto general, las partes interesadas, este, ¿coulders? ¿Eso lo han escuchado? ¿Y qué es? Y sobre interesados, claro, los proyectos. Vas a tener una llamada y lo le dejo. Claro. Entonces, si no queremos redundar en que los partidos interesados de los interesados, para que ya sea normal. Claro. Entonces, si nos queremos redundar en que los partidos interesados son los interesados, podemos decir que son las personas que están directa o indirectamente afectados por el desenvolvimiento o ejecución de este proyecto, en este caso de software. Ya que tenemos una pirámide, la base es la comunidad, gobierno, medios de comunicación, clientes, colaboradores, proveedores, consejos, directores e inversores. ¿Por qué es una pirámide esto? Porque estoy emocionado que el más está interesado, más se viene afectado por el cozo a menor. No exactamente, pero el proyecto. Claro, por ahí va la cosa. La base me habla de donde hay mayor cantidad de personas con menos poder de decisión y acá hay menor cantidad de personas con mayor poder de decisión. Lo que ponen las platas, sabes cómo, ¿Cómo? y justo decir eso, como también puede estar vinculado con lo que hablábamos de las restricciones de dominion y no regles negocios porque por ejemplo hay ciertas aplicaciones que ciertos gobiernos tienen prohibida justo mirar, justo decir eso pero sí, tal cual medios de comunicación claramente los medios de comunicación transmiten una opinión y tienen incidencia en la opinión de esto que te acaso. Clientes porque son los que están más vinculados al éxito del proyecto, no porque son los que se ven beneficiados de él. Colaboradores, proveedores. -Colaboradores y clientes. No estamos con. -No, con no porque los clientes digamos son los que reciben el producto, en instagram que sería el que le. La misma comunidad, pero también la gente que paga los ads por ejemplo. colaboradores serían tercerizados, otras empresas que colaboran en conjunto para generar el producto, o sea, por ejemplo, la empresa que pone desarrolladores, la empresa que pone testers, la empresa que pone infraestructura, bueno, colaboradores. Provedores vendría haciendo un poco lo mismo, pero colaboradores pueden ser como de la misma empresa y proveedores de otras empresas que tercerizan. Consejo directores que básicamente la directiva que, fijen tomar decisiones cuando claramente la dirección era tu metagén. Pero, importa. Personas o grupos directamente, positivos o negativamente afectados por el desarrollo del sistema. ¿Por qué? mi trabajo. Pues. Positivo negativamente. No sé. Muy bien. ¿Me adivinen quién no sabe cómo quitar esto? Yo no. No. Bueno. un momento humilde. Ahí está. Tú. Ahí está. Muy bien. Tipos de requerimientos. Tenemos funcionales y no funcionales. Los funcionales en los que el sistema debe hacer y los no funcionar es el cómo debe hacerlo. Bueno, pero no son los que funcionan, entre los que no. Bueno, les tengo dos spoilers. El primero es que este es una pregunta de cuestionario. La segunda es que la respuesta no va a ser tan obvia, así que entiendan esto bien. Pero ustedes, ¿cuál de estos dos es mas importante? No sé. Porque si no seria muy obvio verdad? Quien da mas? A nivel costos, al no funcional es el que perjudica ¿no? No sé. No, al no funcional si. Los dos son importantes. Claro, pero es como la vaciencia, si no es la mítica, hay algo todo. ¿Qué pasa? No puedo decir que no funcionan, son más importantes que no funcionan, porque si no tengo un "que" haciendo algo, no puedo decir cómo lo hace. O sea, el cómo llegas a la meta digamos puede ser de muchas formas pero lo que tienes que llegar siempre es lo mismo. Entonces como que tenés que tener eso definido y después el cómo lo haces puede variar digamos eso es un poco más flexible. Claro, en términos de importancia los dos son muy importantes porque el uno no puede estar bien sin el otro. ¿Qué pasa? Que a veces pensamos que especificando esto, alcanza. Y cuando dejamos esto de lado, la cosa se complica. ¿S por qué? porque aparece nuestra palabra célebre "retrabajo" y le voy a dar un ejemplo anécdota de la vía real por cierto salió una funcionalidad en un sistema en el que estaba trabajando ¿qué pasa? les voy ao acá. Papá. Papá. Papá, explicarme. Ah. Chico, qué es lo importante. Está. No, pero este es el de su mis desumis. Ya está. Ya está. No, no. No, no. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no Esticiendo sitio por Julieta chico, hago vivo. que se comunicaba con era un proyecto en el que dos sistemas se comunicaban. Esta es el sistema A y este es el sistema A. ¿Qué pasa? Que aquí el sistema A tenía data en crudo. Y la idea del sistema B era poder mostrar esta data como yo quisiera. Es decir, supongamos que yo tenía n registros y yo acá podía seleccionar cualquier registro e ir mostrando el sencillito simplemente esto que está acá, poder mostrarlo acá y seleccionarlo y sin PC esto se hace en un día chicos bueno, además en la especificación cual era mostrar el registro listo, no pasa nada. Está llega a testing rapidísimo y cuando lo voy a probar, el joseo tardaba cinco minutos en cargarme el registro. Y no solo, no solo, o sea, no solamente del malestar que tardaba cinco minutos, sino que ni siquiera me decía cargando ni nada. Era eso y Y El programador hizo uso de sus derechos y dijo "pero la historia no dice que tiene que ser lo rápido" Y yo tuve que aprobar el ticket y abrir un otro ticket para mejorar el perfumo de eso. A ver, está bien, es cierto que la historia no lo decía. Pero eso implicó el trabajo porque implicó que un ticket no va a entrar y se gestionara todo su ciclo de vida por no haber dicho de día antes que no queríamos que durara 5 minutos cargando. ¿Qué pasa? Entonces les estoy diciendo que van a especificar y buscar a ti que va a ser una biblia, no. Pero ahí es importantísimo que el programa o tenga dominio del problema del negocio y de la solución completa. ¿Por qué? Porque de seguro en algún momento si tu te iba a comunicar con el sistema tendrías que haber tenido una sospecha, hubiese sido muy valioso tener la sospecha de que esta comunicación no era liviana y de que eso podía pasar. A ver, pecó el programador por no saberlo, no. Pero alguien tendría que haberlo sabido y tendría que haber sido parte de la conversación en algún momento. Claro, esto fue un aprendizaje y ahora cuando hablamos de requisitos nuevos, ¿y cómo es el tema del performance? O sea, esto va a tardar, ¿qué podemos esperar? Pero bueno, se aprendió a raíz de un golpe, el modo. Y ese requerimiento no es funcional y causó más problema y más polémica que el requisito funcional como tal. Por si es que los dos son importantes. ¿Hasta que tenemos alguna duda? No? Muy bien. Qué bueno, porque en el obligatorio se con una especificada ambos, entonces me quedo tranquilo generalmente están vinculados a cómo se procesa la información a entradas y salidas o vinculados a los objetivos de negocio y las tareas que realizan los usuarios. En definitiva responden qué debe hacer el sistema. Entonces tomando esto, si yo les digo que identifiquen un requerimiento funcional, no sé, de "outlets", ¿qué se le ocurriría? Se muestra el material de las materias. ¿Cómo es? Perdón. Se muestra el material de las materias. Sí, ¿qué más? Pero en que hay mucho? Hay mínimo uno para cada uno. Que los profesores puedan gestionar el material dentro de las propias hablas propias. Ahí va, perfecto. Sí, sí, muy bien. ¿Podría iniciar sesión con un perfil? Sí, claro. Igual, ojo ahí al dato, porque después nos vamos a dar cuenta que hay requerimientos funcionales que están vinculados a requerimientos no funcionales. Eso ten hacerlo ahí en Standby. Aquí tenemos unos ejemplos del querimiento funcionales acá son, cada restaurante debe poder actualizar los ítems y precios de su menú, los usuarios deben poder buscar restaurantes por tipo de comida, los usuarios pueden hacer un pedido con distintos ítems y cantidades a restaurantes abiertos, el sistema de aceptar tarjeta de crédito o débito como medio de pago, el sistema debe generar una factura mensual con las comisiones pagadas por cada restaurante. Y aquí le hago una pregunta, porque hasta acá se ve hoyo, pero ¿qué pasa? Julieta, necesito tu ayuda porque voy a usar el goso de Zoom y capón en la otra. El sistema de aceptar tarjeta de crédito de débito como medio de pago, ¿verdad? ¿Qué pasa si esto dijera el sistema de aceptar tarjeta de crédito débito como medio de pago ¿verdad? ¿Qué pasa si estoy jera el sistema de aceptar tarjeta como medio de pago? ¿Qué le estoy? ¿Qué le estoy sumando a requerimiento quitando esta palabra? Amigüedad Amigüedad O por lo menos insertidumbre ¿no? o por lo menos una pregunta ¿qué pasa? ¿qué pasa? que capaz aquí él no tiene con su una tarjeta si, si, luego que me decías que se me daba la tarjeta no se, y apanse por su una tarjeta no sabemos si en el negocio existió otra tarjeta que no es de banco. Claro, es un salario. Entonces, yo creo que siempre quitar los palabras, pero esos palabras bastaron para abrir incógnitas. ¿Qué no le falten estas palabras? A los requerimientos de ustedes. O al dejar de las dos palabras también se da. Tendría que poner solo de evito y crédito. Pero capaz que algún banco que no. ¿Pero qué es esto? y crédito. ¿Qué es la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parte de la parteutos de calidad, hablamos de características que son diferenciadoras a nivel competitivo con otros productos. ¿Cuáles son estos atributos de calidad? Esto no me quiero decir todavía. Nosotros vamos a ver algo. La próxima clase, claramente uno. ¿Qué es la ISO 25000 Pero está eso, básicamente el lija habla de cuáles son nuestros atributos de calidad y bueno, nada de positivo, no tenemos, no pasa nada, pero si lo resuelven para la próxima clase, decirlo que mejor. Vamos a ver cosas como usabilidad, escalabilidad, bla, bla, bla, bla, bla, que si bien no son las funcionalidades, si el sistema pueden ser determinantes para que un usuario elija un producto por encima de otro bueno antes de terminar recordarles que la clase que viene o sea el puede tienen que venir presencial si o si para la evaluación 1 y tienen que traer computadora si o si con todo instalado si o sí y sí o sí va a tener que hacer la evolución si que yo le responda nada eso bueno dicho eso que descansen buenas noches