Especificación de requerimientos casos de uso e historias de usuario

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

Resumen

La sesión se centró en la etapa de especificación dentro de la ingeniería de requerimientos. Se repasó que los requerimientos ya identificados y analizados (priorizados y modelados) deben aterrizarse en una especificación formal. Se explicó que la especificación puede adoptar dos enfoques: el tradicional, basado en casos de uso, y el ágil, basado en historias de usuario. Se detalló la estructura de una historia de usuario (identificador, título, expresión 'Como [rol] quiero [funcionalidad] para [beneficio]' y criterios de aceptación) y se introdujo el modelo INVEST (independiente, negociable, valiosa, estimable, pequeña y testeable) para evaluar su calidad. También se presentó la plantilla de caso de uso, con actores, precondiciones, poscondiciones, flujo normal y flujos alternativos, destacando la importancia de documentar los flujos alternativos y vincularlos con los pasos del flujo normal. Se realizó un ejercicio práctico donde los estudiantes transformaron un caso de uso en una historia de usuario, identificando requerimientos funcionales y no funcionales. El docente enfatizó la necesidad de evitar ambigüedades, medir los requerimientos no funcionales y considerar los flujos alternativos en los criterios de aceptación. Finalmente, se discutió la diferencia entre épicas e historias de usuario, y se aclaró que para el obligatorio solo se requerirán historias de usuario y casos de uso, sin épicas.

Puntos clave

La especificación aterriza los requerimientos identificados y analizados, priorizando y modelando.
Existen dos enfoques: tradicional (casos de uso) y ágil (historias de usuario); en la práctica se combinan.
Una historia de usuario es breve, atómica e indivisible, con estructura: identificador, título, 'Como [rol] quiero [funcionalidad] para [beneficio]' y criterios de aceptación.
El modelo INVEST evalúa la calidad de una historia de usuario: independiente, negociable, valiosa, estimable, pequeña y testeable.
Los casos de uso incluyen actores, precondiciones, poscondiciones, flujo normal y flujos alternativos; estos últimos deben derivarse de pasos específicos.
Los criterios de aceptación deben cubrir tanto el flujo normal como los flujos alternativos para evitar ambigüedades.
Las épicas agrupan historias de usuario relacionadas con un objetivo de negocio; para el obligatorio no se requieren épicas.

Transcripción

Bueno. Ahora podemos comenzar. Eh, los que están en remoto me confirma que están viendo el cronogramas. Sí, pero es verdad. Gracias. Y aquí estamos prendiendo más la camarita. Eso. Muy bien. Bueno. es ¿Qué? el dominio del problema y poder hacer el análisis correspondiente para identificar estas soluciones que íbamos a proveer y las que íbamos a describir a través de requerimientos, ¿verdad? Después hablamos de la ingeniería de requerimientos ya como un proceso y nos dimos cuenta que la ingeniería de requerimientos como proceso tenía actividades que empezaba con la licitación, luego venía el análisis, luego venía la especificación, la validación y de forma gíclica volvemos a eso. ¿Ya? Muy bien. ¿Qué vamos a tratar de hacer hoy? Hoy vamos a hablar sobre especificación que no va a ser más que poder aterrizar estos requerimientos que ya identificamos y analizamos y que significaba analizar significaba priorizar significaba modelar ¿Por qué? Vamos a partir de una pregunta que Luca no va a poder responder porque él ya trabaja de esto entonces no se tiene que imaginar nada sino que ella lo sabe entonces él no participa pero de resto nadie más trabaja con su amor cierto cierto nada yo no también me mientas tú sabes no no ni ahí bueno bueno para aquellos que no saben? O sea, todo vino Luca. ¡Ah, tengo un marcador, chicos! ¡Qué bueno! Nunca… ¿Qué dice? ¿Cómo que es que es marcador? Siempre he dicho. Sí. No se puede decir abajo. Sí, pero oídos. Bueno, no importa. Supongamos que mañana arrancamos a trabajar. Somos unos programadores full stack. Y eso que voy a explicar. Que vamos a tener que arreglar problemas mejor conocidos como vos, cierto? o vamos a tener que implementar funcionalidades nuevas o construir un producto nuevo si o no, hasta que cada vez estamos de acuerdo hasta acá estamos de acuerdo, es la idea, es lo que se espera, está, entonces mi pregunta es si usted va a estar a cargo de codificar y construir algo o arreglar algo que ya está hecho que espero que usted recibió una documentación ok es gracioso porque después cuando hablar de documentar lo odien pero lo primero que esperamos recibir para trabajar de esta documentación un misterio documentación muy bien y como esperas de la documentación porque yo te podría dar un ojita y decirte hazme una app linda no bueno yo me refiero así tenemos que haber algo vamos a ver si le pregunto ¿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é? No, no ven. No ven. A ver. No sé si bebe mucho. Ahí veo creo que demasiado. No, no, no. Ahí. Ahí veo letras. Veo. Bueno, lo que ves es lo que hay ahí. Bien, bien, bien. Perfecto, ¿no? Para qué más? Bueno, muy bien. Claro, recuérdame. Cuando se empiece a dejar de ver, me avisas y borro y volvó a esta zona. Entonces, ¿quién es Rihirka? ¿Qué hacemos? ¿Qué hacemos? No. Sí, sí, sí. ¿Qué hacemos? Ok. ¿Qué hacemos? ¿Qué debemos lograr? ¿Qué debemos lograr? No, no lo dices. ¿Qué deb ¿Me vemos? Voy a ver. Y te voy a dar cuenta que hay una pregunta bastante interesante. ¿Cuál es la definición de qué hicimos lo que me estás pidiendo? Sí, también de que era la siguiente del cien de Paraguay. Claro. Claro. Sí, sí. y de esa imagen. Entonces, de vuelta a la pregunta inicial, ¿qué creen ustedes que necesitan para poder trabajar bien en un proyecto nuevo más allá de un onboarding y todo lo demás? Necesitamos sin duda tener actualizados los requerimientos a través de una documentación que va a ser una especificación de requerimientos y como se los llega adelante en otra clase, aquí donde ustedes mismos se dan la sopa al cuello eh para el obligatorio porque quieren que preguntas que ustedes quieren que cosas que están definiendo ustedes acá las respondamos nosotros después rarísimo pero bueno eh para y pasamos muy bien entonces que de que va a ir esto. Vamos a ver acá los enfoques, ¿s es? ¿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é va a representar esta especificación? Los requerimientos que ya habíamos dicho que pudieran ser requisitos funcionales y requisitos no funcionales, ¿sí o no? Y que también habíamos visto en las diapositivas que en realidad hasta ahí, es una lista verdad que declara cosas el sistema debe hacer esto o el usuario debe poder hacer esto si entonces esa lista verdad que tiene un rf 01 y que más tenía esto esta lista que les dije por favor no se olviden de tener esto presente porque va por el legado de la excisión de estabilidad. Tenemos el identificador. La descripción del requerimiento. Que no falten. No, eso es lo que va a ver acá. La prioridad. La la prioridad muy bien lo pueden hacer. ¿Qué es eso? pero esto cada un recirimiento o un conjunto de estar requerimiento va a ser especificado. Si. Y esta especificación más puede tener los enfoques, el tradicional volar. En la práctica, en los equipos de hoy en día, si utilizan ambos, no, pero representamos los dos para que podamos compararse en una pequeña reflexión al final. ¿Hasta acá estamos bien? bien de hablar. Y estamos en la etapa específica. Ah, el que lo abro. Está. Entonces, a modo de recap y pretengan atención a esto porque vamos a hacer un ejercicio más tarde y lo vamos a tener que hablar. Eh, habíamos hablado de que, que cosas hacer que un requerimiento estuviese mejor definido o no también definido. Y este es un pequeño repaso.aso le damos por favor porque puede ser que hay una pregunta de cuestionario de esto y no queremos que pegan en esa nana, si no sabemos, pero tenemos una ambigüidad, correctitud, completitud, consistencia, factibilidad y verificabilidad, y aquí tenemos unos ejemplitos. No voy a pararme mucho acá porque más tarde vamos a hacer un ejercicio y el recurso lo vamos a tener y la ir a utilizar. Pero vamos a seguir mientras está. No importa. Así importa, pero lo van a leer ustedes más tarde. Así que seis minutos. Bueno, historias de usuario. Luca, qué buen historio de usuario. Asumo que bueno. de la solución para que cubra eso manera. Hay una palabra claridad que desde la perspectiva del usuario. Este contraste lo vamos a ver en un ratito. Ahora, ¿qué dice la teoría de la diapositiva de que es cuando yo no te remito a leer? Una historia del usuario es una descripción breve y simple de una funcionalidad del software desde la perspectiva del usuario final. Perfecto. Entonces, ¿qué pasa? ¿Qué característica en particular tiene el historio de usuario que la va a diferenciar como vamos a ver en un ratito de los casos de uso? Breve. breve atómica qué es el botónico son chistos indivisible. Indivisible. Muy bien. Viste que estoy sabiendo. Me están mintiendo. De parte de Patillerato tenemos una, tuvimos una materia parecida a esta que era análisis y diseño de aplicaciones. Ah, eso es horrible. Como madre. Está llegando a la mierda. Ah, entonces es perfecto. Esto no puede ser normal. Los recordemos la fiesta entonces, no más la, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, ¿Por qué no vale la verdad? ¿De dónde yo vengo? Está indivisible. Lo mucho que yo decía que esto sucediera en la práctica. Pero bueno. Entonces, estamos diciendo que esto nos va a permitir especificar los requerimientos que tenemos. Podríamos pensar que esto va a tener una especie de plantilla o estructura y de hecho la tiene. Se me darán todo lo que importa. ¿Qué pasa? Si estamos hablando que esto es atómico, ¿verdad? Tendría sentido pensar que hay una especie de categoría más grande que las pueda agrupar, porque al final un sistema puede ser más o menos grande, pero puede que tengan muchas funcionalidades que pertenezcan, digamos, a un mismo objetivo de negocio. Entonces, en este sentido tenemos las ép? Y las iniciativas que agrupan épicas. Atención con lo que llamamos objetivos al negocio, ¿no? Porque qué pasa acá? Que en realidad como una historia de usuario es algo más atómico y puede que haya objetivos de negocio que implicuen muchas muchas funcionalidades. Ahí es cuando hablamos de ética, por ejemplo, hay una palabra brista que nos ayuda mucho a entender cuando estamos hablando de algo que es más grande y que se tendrá que poder componer y es la palabra gestionar. Entonces, ¿qué pasa? Que a veces nosotros nos vemos en la tentación de generalizar con la palabra gestionar, sobre todo cuando definimos requerimientos o con esto, y en realidad eso nos da una pequeña sospecha de que se pueda componer en otras cosas. Por ejemplo, si hablamos de gestionar estudiantes en un sistema universitario o académico, lo que fuese, ¿qué significa gestionar para empezar? ¿no? Puede ser dar de alta, dar de baja, cambiar de estado, asignarlo a determinado curso, etcétera, etcétera, etcétera. Incluso, no sé cómo funciona acá, pero en la universidad en la que yo estaba, cuando estudié mi primera carrera, y es que no podías cursar otra materia más que la que ya venías refrobando y no puedes escribir otra materia esta que pases es bueno, esa es parte de gestionar a estudiantes ¿no? Me pongo una época de dulce Entonces, ¿qué ocurre? Que no vamos a hablar de una historia de usuario que haga todo eso, eso sería una épica gestionar estudiante ahora que si va a ser algo más antónico bueno, asignaron estudiantes en el estado R, darlo de alta, darlo de baja, modificarlo, cambiarlo de carrera se entiende la diferencia entre épica y historia de usu usuario hasta acá? ¿Sí? Ok. Entonces hablando de la estructura de lo que punto no vemos. Perfecto. ¿Y ahora? Perfecto. Ah, ok, cool. ¿Cállate tarjeta que interesa tu acción y conversación? Ah, no se ha agarrado. Ok. La K es esto, que está acá. Si, ¿pienes que nos habla de que la historia de usuario va a tener un identificador y un título, va a tener la siguiente expresión. Como usuario quiero una funcionalidad o capacidad para beneficio. Entonces, ¿qué ocurre? ¿Se acuerdan que cuando empezamos el curso hace varias semanas atrás hablábamos que uno de los problemas que solía tener el ingeniería de requerimientos solía es que a veces no se entendía bien el valor que iba a aportar y eso siempre lo pregunten, no exitosos. Bueno, básicamente ese para que dice ahí lo que busca es asegurarnos de que lo que estamos construyendo va a cortar un valor y es lo que busca responder ese paro. Ese cómo es el rol de usuario y generalmente puede ser un actor dentro del dominio del problema y el que básicamente lo que se va a hacer. Si los criterios de situación van a hacer una lista que nos va a permitir definir el comportamiento del sistema a través de la implementación de lo que estamos haciendo y además poder entender cómo el sistema va a manejar ciertos escenarios. Qué pasa? Que hablamos de que este es atómico, ¿verdad? Y como estamos hablando que la hospitalio de aceptación nos va a definir un conjunto de comportamientos, hay que tener cuidadito. ¿Por qué? Porque si esto se nos va demasiado largo, capaz, ya estamos empezando a mezclar historias de usuario en una sola y hay que tener cuidado de no hacer eso. Pero un solo criterio de aceptación deja mucho que desear, porque de la pregunta que les hice más temprano que esperan ustedes recibir cuando empiecen a trabajar y si les dan esto y no solo la palabra y te aquí y tantas cosas que pueden pasar capaz se les queda corto. ¿Qué teoría acepto? Cada tarea tiene un número estimado de días para realizarse y un porcentaje completado. OK, perfecto. Ya tenemos elaborado esto y esto. Esto es importante. ¿Por qué? Porque al final del día se supone que como estamos en metodologías ápiles y estamos a los equipos multidisciplinarios que colaboran entre ellos para dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar, dar,icas, card, conversation y confirmation. Confirmation es lo que se hace a través de la pictoria de la situación que es lo que tenemos acá. Voy a enfocarme en la conversación porque las otras las hablan. Pero la conversación es lo más valioso, la de tener una historia de usuario, Bueno, ¿remotos sabemos? No, no. hubo un diagrama que les mostramos en la clase de procesos que era un esquema muy simplificado de Scrum. Y en un pedacito en lo que decía Product Owner. Product Owner es básicamente el rol que se encarga de administrar el producto y tomar decisiones de hacia dónde va a ir y él está más familiarizado con las necesidades que se encuentran en lo mínimo del problema. Por eso es que la parte de la conversación es importante porque esa persona que está tan ligada a esas necesidades no quiere resolver todo y vamos, vamos, vamos, vamos, vamos, pero bueno, limitaciones y por eso es que el equipo tiene que estar como en consenso con eso. Además de que no necesariamente las ideas que plasme este rol van a ser entendidas por todo el equipo, sobre todo si el programa es nuevo por por ejemplo, o el test es nuevo por acá. Hay muchas maneras de llevar a cabo esta conversación. Una de las más reconocidas, digamos, o más conversadas es una reunión que se llama Refinance, que es para precisamente refinar este artículo. Abreme un d hasta acá? Te veré como el agua muy bien. Ahora, ¿qué pasa acá? Como estamos hablando de un artefacto que nos va a permitir aterrizar los requerimientos y esto es importante que este, digamos mejor especificado posible hay un modelo que se llama invest que nos dice si está en sí, estos criterios usted va a tener un historio de usuario de calidad y un historio de calidad le va a permitir disminuir la incertidumbre de que haya ruido en la comunicación en tu productor y el equipo de sarmitista. ¿Qué significa invest? Cada letra tiene significado crónico y es independiente, negociable, valiosa, estimable y es mol que es de ser no pequeño. ¿Tienes que esto es pequeño? Ya por determinación la tendríamos cubierta. Valiosa la tendríamos cubierta. Valleosa, la tendríamos cubierta. Negunciable, está por acá. Valleosa, también está por acá. Y estimable… -Eso no es el independiente que le va a dar. -Pues el independiente también está por acá. -Independiente. - no. Y estimable es la parte interesante de todo esto, ¿verdad? Pero vamos a leer cada uno. Independiente tiene que ver con que no exista una dependencia demasiado notorio entre las historias de usuario, entre ellas. A ver, hay situaciones en las que es entendible que esta dependencia surga, pero las buenas prácticas nos llaman a tratar de evitar eso. ¿Por qué? Porque la idea es que si tenemos un equipo de no sé, en desarrolladores, ellos puedan trabajar en tareas de formidio pendiente y no chocarse entre ellos. ¿Qué tanto pasa esto en realidad? Vamos. Neb oficial es básicamente poder tener esta conversación de la que hablamos para que realmente refleje las capacidades del equipo versus la solución que se tiene que dar a un problema negocio real. Valuce el caporte de valor y esto a veces se determina bastante bien en la parte de la conversación a través de los negociables y de hecho yo estaba en equipos en que los programadores cuestionen al producto, le dicen pero esto realmente aporta valor. A usted parece. Y eso es bueno. ¿Por qué? Porque primero nos habla de un programador que conoció un producto y tiene una visión amplia. Y por eso ustedes ven este tipo de asignaturas. No creo que nosotros pretendamos que sean product owners, o sea, si son product owners de más. Pero el criterio es importantísimo y es algo que yo les digo que rescaten lo más que pueda. ¿Qué tanto conocimiento tenga por lo que no puedes estimar si no sabes sobre qué les cojamos? Si no está muy bien especificado va a ser más difícil estimarlo, cierto? Y también es cierto que entre más se corrompa el criterio de que sea pequeña, más difícil va a ser estimarla porque vas a tener que ir pensando en unas cosas hallacentes, hallacentes, hallacentes y bueno, se va de largo. Y lo peor es que pues dicen esto no va a tomar ocho días, ¿cómo que ocho días? Y lo tienden que está listo mañana, bueno, tan idea. Pero digamos que estimable y esta parte estimable está muy, muy, muy de la mano al que sea verificable también. Eso. Ya les avisa que ustedes van a tener que demostrar que su editor de usuario cumple en vez de o no lo verán por favor esto no lo vamos a asaltar ahora casos de uso de historias usuarios hay alguna pregunta o seguimos está perfecto ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿Pero qué es eso? ¿P dos factores pueden ser otros sistemas? ¿Qué pasa con las fases de uso? ¿Qué pueden tener una plantilla? ¿ y pueden tener un diagrama? y esta plantilla va a ser mucho más formal ¿Por qué? Porque recordemos que esto viene de un enfoque más tradicional y en estos enfocos tradicionales los equipos se apoyaban más en proceso y documentación rigurosa y acá no apoyamos más en equipos multidisciplinarios, personas y aporte de valor. ¿Tinifica que esto no aporta valor? ¿Sí? ¿Preguntan? Ok. Entonces, los casos de uso son una descripción generalizada de un conjunto de interacciones entre el sistema y uno o más actores, donde un actor puede ser tanto un usuario como otro sistema. Eso ya se los había dicho yo, pero ahora con orden. Todos aquellos que interactúan con el sistema representan un actor, pueden ser humanos u otros sistemas, representan roles que los usuarios pueden asumir. Característica, un caso de uso puede tener varios actores. Un actor puede interactuar con varios casos de uso, se pueden describir formal y informalmente, acá lo vamos a ver un poco más formales, se pueden escribir en forma textual y diagramática, de ahí enmos cuándo vamos a trabajar acá y el conjunto de casos de uso determina la funcionalidad completa del sistema. Entonces, mientras acá teníamos iniciativas que se descompunían en épicas, que se descompunían en historias de usuarios, acá vamos a tener un documento de especificación de requerimientos que se va a desglosar en casos de uso y en la especificación de cada uno de esos casos de uso. Ustedes no van a hacer eso como esta especificación de requerimiento tal cual. Nada más como el alcance del obligatorio está chico, en realidad simplemente vamos a tener historias de uso ahora con un lado y caso de uso por otro. Pero no, no se planteen ni siquiera el tener que definir épicas porque eso no va a suceder para obligatorios. Este Este es un ejemplo de cómo es una plantilla de caso de uso ya la voy a. Fíjense que mientras que acá teníamos la tarjetita con tres cositas y la preceptación aquí ya tenemos algo mucho más riguroso. Sí. Vamos a revisar qué tiene. Tenemos su identificador con un nombre descriptivo. La descripción que es la descripción corta de quién va a hacer por qué y qué obtendrá. Fíjense que aquí, aunque no haya un para, en la descripción tendremos… Perdón, lo he hecho mal. Fíjense que aquí, si este está bien escrito, tendríamos que poder resolver esa pregunta del que obtendrá y ese es el aporte de valor que va a tener aquí en el producto. Actores involucrados en el caso de uso, precondiciones y poscondiciones. Importante. O sea, de las cosas más valiosas que pueda aportar es tener la parte de precondiciones y poscondiciones. ¿Por qué? Porque recuerden que esto va a ser, esto es, según el enfoque tradicional, es lo que usted puede recibir para el programa. Y si esto ya le dicen que precondiciones se tienen que cumplir para eso, de una forma bastante implícita, le está presentando lógica que tiene que aplicar también. Eso es importante. ¿Qué esondición, condiciones que se cumplen antes de iniciar el caso de uso. La más, digamos, trillada si se quiere y no es necesario que la coloquen porque después van a ver que si la misma precondición se repite en todos los casos de uso, entonces ya no necesitaría especificarla porque está en todos lados. Pero una precondición para acceder a mi perfil es estar logueado. Hay otras precondiciones que a veces se buscan simplemente para rellenar que no hace falta. Por ejemplo, tener conexión a internet. Sí, bueno, con una precisación web, sabemos. Ojo, ojo, que tendiendo el objetivo del caso de uso, puede que eso sea relevante. Por ejemplo, si lo que queremos verificar es el comportamiento del sistema cuando la conexión es lenta, ahí se vale la pena decir precondición contar con una vez que no tenga tal velocidad, por ejemplo. Esta es una precondición valiosa. Y las condiciones es lo que ocurre luego de que se termine el caso de uso. Por ejemplo, si estamos hablando de un sistema en el que yo me voy a… Ah, un carrito de compra, más clásico que posible. Compré un producto y una de las pos condiciones es que el usuario recibe un correo de su compra por exitosa y aquí puede traquear. Eso es una de las que termina el caso de uso comprar. Entonces, por eso es una pos condición. Luego, fíjese, hago aquí interesante y es que tenemos dos secciones. Flujo normal y flujo alternativo. El flujo normal es lo que se supone que tendría que suceder, que también se le conoce como camino feliz o haja de paz. Y los flujos alternativos son los, bueno, que pasa así ocurre esto a mitad de camino. Por ejemplo, un logis que es de los ejemplos más sencillos que se utilizan para explicar estas cosas. El primer paso sería que el actor ingresa soscrencial, ¿verdad? Y después hace que… y el sistema al final le dice, "Bueno, bienvenido". Pero ¿qué pasa si la contraseña es equivocada? Ah, bueno. Ahí nos venimos a la parte del flujo alternativo y fíjense que aquí dice 2.1. ¿Qué significa 2.1? Que es es la difurcación a partir del paso 2. Entonces tengan eso presente. Cuando vayan a documentar los casos de uso en el obligatorio, tiene que asegurarse de que todos los pasos estén denominados y que el flúcal del mantivo corresponde con el paso del cual está derivado. Y fíjense que no importa si el flúco normal o el del mantivo, siempre va a estar dividido entre la acción del actor y la reacción del sistema. ¿Alguna provocada acá? El flujo normal en todos y en todos los flujos alternativos? No, no, no, no. Si puedes tener más de un flujo alternativo en un caso de uso de distintos pasos, pero eso depende también del análisis, ¿no? ¿Qué ocurre allí? Ahora, de vuelta, que divino, ¿no? Y usted imagínate llegar a trabajar, a programar un lugar y que te den paso por paso todo lo que tiene que hacer ya le aviso que eso no lo… pero bueno, así era antes en la época de otra gente no bueno, muy bien Y aquí tiene un ejemplo. Ahora, primer reto que tienen ahora y van a tener cinco minutos. Leas ese caso de uso. Pero para que no llegan. Pero les voy a dar tiempo. Bueno, diez minutos. pero ni siquiera sabes que te llamas así para que no se le da nada, no se está diciendo ah que no se le da bien ah bueno bueno bueno perdón ahí ve. Los remotoven. ¿Qué se ve? ¿Para eso? Las impositivas están en aula chicos, las voy a descargar. Solo digo. ¿Qué van a hacer? Van a transformar. Siñían. Por fin. Vamos a, no estén aburridos. Eh, transfer, o sea, primero le de uso entiéndalo y transformen en un historioso hoy bueno la G25 vemos eh lo que nos parece lo que nos parece también miren que además ustedes son los que pueden convertir pantalla y que por cierto mañana y mañana les mando el cancel checkpoint. Oye. Pero ya de mano les digo tendrían que ir cubriendo las tinkas de la situación que ya vimos. Ah, ok. ¿Qué pasó? No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, a ver si le digo la verdad podría exigirle que te apresencia pero vamos a dejar presenciales nada más las evoluciones lo que he selectido es que la la modalidad sea consistente de trabajar todo el grupo que quiere decir eso que todo online o todo presencial pero no lo puedo el unión porque es complicado para mí, es complicado para ustedes porque entonces tus compañeros escuchan su revisión y el réincomo. Ya les aviso, los presenciales bajan tener prioridad, o sea, yo voy a tener primero los presenciales porque al final del día tengo que desviver al online. No venía nada de presenciales porque al final del día tengo que ir a la hora dentro. No venía nadie presencial. Te veo un raro sin colíe esto, usted. Te veo un raro sin colíe esto, usted. Ya, ya, ya, ya, ya, ya, ver por qué yo pero mandé mi correo y tal. No. No. No. Cústso ante el check? Imagínate. Profes, la PPT donde está lo que la PPT está pasando recién es la de check list de requerimientos y casos de uso, no, no. No, no, no. Material, diapositivas del curso y la diapositiva se llama especificación de requerimientos. Bien, gracias. >> Bueno. ¿Capas tres minutos más? O alguien ya está como para… ¿No? Bueno, está asesado. Voy a tristar aquí, hijo. >> >> Pero fue una consulta. Sí, díganme. Un criterio de aceptación sería que el cliente tiene que ser socio. Vos dale y esperálo para no se les puede ir a los demás, pero tenedla y un gol. Bien. y >> Vamos. ¿Qué digo? Bueno, entonces comentamos con nuestro amigo Pablo. ¿Cuánto es que tenés aceptación, Tiengik? No, pues yo… 6. 6. No estamos convirtiendo como la otra vez por la duda. Está. Eh bueno, contamos. Contarnos cómo tenés la cara. Eh. Y de uno hasta uno. Ok. Para. ¿Los remotos están escuchando paulo y brisa escucha ok adelante para hacer un poco de sentido que no. Ok, cuando se le hace un día, eso es el sistema de otro área, sus púlpures, y lugar a dedicarlo. Ahí va, perfecto. Piensa que, a pesar de que el caso de uso no está presentado como un historio de usuario, no es la información necesaria para generar una. Eso significa que en realidad los dos no aportan. Cambien la forma. Ahora tengo una pregunta. Fíjate que tenías con criterio de aceptación que hablaba de que si el usuario estaba bien con la cuota iba a poder reservar. Como programador no no piensas que te gustaría tener otro que usted es de esa acción que te diga qué es lo que tienes que codificar en caso de que no tenga la cuesta al día porque puede se podría manejar de muchas formas, podría hacer que el botón esté deshabilitado podría hacer que no va a llegar ni siquiera esa pantalla entonces no aplique o nadie se dio cuenta y se liberó un poco de producción y vaya, vaya y pase. que estarán ya con la cuarta para hacer un gran resultado de la cantidad y los partimientos de la cantidad. Perfecto. Es que más o menos no es yo y no vamos a tener nada ahí. Claro, y fíjate que solo puse definir porque el Case d'Uson nos ha dado el curso alternativo ¿verdad? ¿Cuál? Claro, ¿y cuál era por alejar esto? Asegúrese que en su criterio de aceptación también cubra el fútbol alternativo. ¿Verdad? Bien, eh… No, no, bueno fuiste de ¿no? Ah, aspecto, estamos en familia. Eh, a los que están en remoto, le voy a crear el break room. Es que trabajen juntos, ¿eh? No, cada quien por su lado. Eh, igual tengo unQué? ¿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é? >> Ok. Amigos, si venimos a la parte de material general y requerimientos, tendría que poder ver esto que hice enunciado Jimpeth. ¿Me confirman? En material general y bajan hasta la sección de requerimientos que es la tres y tendría que aparecerles en un cedo si les sale. Bueno, abranlo. Entonces, cuál es la idea acá? Acá es lo que te iba a hacer el siguiente. Hay dos partes acá. La primera, van a identificar requerimientos funcionales y no funcionales. ¿Tá? Esa es la primera parte. Y la segunda parte es que después van a especificar esos requerimientos funcionales y no funcionales a través de casos de uso o historias de usuario. Entonces, ustedes lo van a hacer con caso de uso y ustedes con historia de usuario. Y lo remoto, comenzamos con ustedes. ¿Te entiendes? Los voy a agregar entonces a la break room. Identificamos requerimientos y vemos que si hacemos caso de uso o historias de usuario. Ajá y después lo especifico. Perfecto. Bueno, en marcha entonces. Está. Pidenciena cosa. Le quiero entrevistar a dos personales. Uy, personales. ¿Qué pasa? ¿Este es unimiento es funcional RF01, si es no funcional, RF01, pero nunca lo menos sirve. Segundo, hay algo que se llama "Boss ActiGolf". ¿Qué significa esto? Que se tiene que hacer explícito si es el sistema o el usuario en el que estoy involucrando el requerimiento y la consecuencia. Entonces, ¿cómo se podría escribir esto de otra forma? El usuario ya puede ser con instan y con estas embatosas. Exacto. El sistema, por el otro punto de vista el sistema debe permitir al usuario registrar sus datos personales hasta aquí se le habían cierto? ¿Qué lograría lo más? Lo que corresponde. Atención a esto, nos queremos quitar nota por no aplicar la OVP. Bueno, ahora decidme uno lo funcional. Si te va a dar esta de fácil accesion para los swipes. ¿Cuáles creen ustedes que son los desafíos de este requerimiento? Pero sí, es una fácil exceso y que es… Exactamente. ¿Y qué corre aquí? ¿ Que aquí es donde el ingeniero de incremento tiene que saber cómo medir eso. Entonces nosotros más adelante vamos a ver y ahí voy a madurificar, teorítica, que nos va a ayudar un poquito a realizar esto. Pero en momento así está bien. tienes otro no funciona ¿Qué pasa? Aquí un poco lo mismo ¿no? ¿Qué significa que está protegido? ¿Cómo? Porque por ejemplo, ustedes para el obligatorio tienen que el sistema que y esto tiene que verlo un poco más. ¿Cómo? Debe seguir el protocolo X y Z. Debe estar, no sé, la información sensible está la encryptada con tal, pero siempre ponerle el cómo se verifica eso. ¿Verdad? Muy bien. ¿Qué pasa? El enlucidor no lo dice, pero es que divinen, un cliente no les va a decir eso tampoco. Y esta es la ciencia de esto. Son decisiones que vamos a tomar más solos. Ahí tenemos la libertad de que es igualidad, lo que más cuando le estamos en la solución. Ustedes pueden proponer y explicar pros y contras. Lo más probable es que te digan, sí, sí, vos fijate. Pero bueno, al final en papel tiene que estar algo que no habría pedido, de que es la investigación de datos personales, ese que acaba de borrar. Los usuarios deben poder hacer datos personales para poder registrarlos o actualizarlos. Hay otro usuario que me dice tener un usuario creado. Uno, seleccionar modificar datos. Ay, me fue adentro de la resolución del sistema. Que si no esta inversión del sistema tiene un error, entonces hay otros modificados a todos. Esa es la que no traduye con el T. No, no, no es que tipo, sería una puma de que te tiene un error. Si vos eres una precondición, te dejes ponerlo con mi paz, si estás recondición ¿Por qué no llega a ser el segundo? selecciona un campo de guitarra, 4 sistemas que habría escrito en el campo, 5 escribiendo el campo, 6 se va mostrando lo que está escribiendo, tipo se va a rechegar el link, selecciona el botón de guardar campus. Si no hubo cambios entre que se invitaría a página y se toque el botón, el botón donde estáagitado también va a haber al menos un cambio. Y si el valor no es valido para el campo, me hace un error debajo del dinku, del rojo, con la razón. Tiene que sumar un rey. -Aquí está una cosita. ¿A quién está faltando? ¿Cómo termina el caso de uso? Porque puede ser, si tenemos, ¿dónde le aguarda. Claro, ahí y ahí eso, ¿no? Ahora fíjate, flow alternativo, sino en cambios, entre que se ingresó la pantalla y se salió, el botón se muestra deshabilitado. ¿Sí? Esta reacción que está acá, que lo que se acerca es preguntástica para no te entendí bien, dice, si el valor no es válido para el campo muestra un error de apoyo de línput en rojo con la razón. Esta no es una reacción del sí, o sea hasta acá es una reacción del sistema, pero si el valor no es válido para el campo en realidad es otro lo cual termo porque una cosa es que no cambien nada y otra cosa es que ingresé un valor no válido. Si ingresó a letras en el peso. Claro. Entonces ahí está. Ahí estábamos hablando de dos flujos alternos diferentes. Sí. Y fíjate algo. ¿Qué capaz? 7.2.1 y 7.2. Ok. Eso era mi clavo plan. Por ejemplo, 7.1 y 7.2. es algo que capaz. Fíjate, aquí tiene 7.1, si no hay cambio entre que se ingresó a la pantalla y la reaccioné, el botón está deshabilitado, porque se lo respetó el sistema antes de ser poco eterno, y otros poco eternos, se inges con los historios de usuario tienen el equivalente justo a este. Sí. Está bueno. Ahora vamos a vamos a ver cómo quedan los historios de usuario. Muchas gracias, chicos. Uy, eso son los trozos. ok ok. Igual tenés la mano ahí en el caseduso para ver la equivalencia. Registrar a estos personales como clientes. Ustedes habían hecho también como cliente. Como usuario. Como usuario. Ok. Quiero registrar y/o actualizar datos personales para que mi información esté siempre actualizada para mi entrenador. ¿Puesta que ustedes o estaban en el enunciador? No, vamos a ver, por que hay un plan en el salario, se oposimos que era la persona que echó la venta. Si ustedes tuviesen que hacer ese sistema, hubiesen seguido adelante, ¿con esa exposición? ¿O es algo que ustedes se han preguntado? Mmm… Pero es supuesto, pero es supuesto, no es algo. Ahí va, muy bien. Fíjense, fíjense, como el hecho de que el formato del caso de uso te obliga a llenar flujo alterno un poco te llegó a pensarlo, ¿no? Aquí nos estaría diciendo falta un criterio de aceptación que maneje ese tipo de cosas. El que pasa así lo aguarda y no hay nada. Ah, claro. Sí. Entonces recuerden, ese tipo de señores también se tienen que representar en los criterios aceptados. ¿No? Muy bien. Bueno, muchas gracias. Eh, ahora vamos con… O sea, en mi caso de que como que no estoy de edad, pues no. Habría que tener en cuenta eso. No, más que todo el tema de que pasa si voy a ir a registrar y hay problemas con los datos. 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. No. No. No. No. No. Sí. No tengo tengo un tema de conexión acá pero les voy a pasar la web para así la a todos personales como peso, alturametros o metros objetivos de entrenamiento los objetivos de entrenamiento serán atributos de la clase persona. No, no, tendría sentido hacer una parte. Es que el pedrilla tiene que ser este, pero no lo hubo este. No sé. No, por ejemplo, el plan de esto en la repartición y ahí tiene su propia rutina, plan de esta y cosas, ahí tiene otra rutina. Correcto. Yo también lo veo así. Este y otra cosa fíjense que acá nosotros lo pensamos de esta forma, cierto? Pero en realidad, dependiendo del gimnasio, estos datos capaz no registran el entrenador y no la persona. Porque a veces tú vas con un gimnasio y te inscribes y a ti te preguntan esos datos y ellos lo registran en su propio base. ver qué es lo que busca el usuario. No quiero llegar a la conclusión de que una respuesta está bien o que la otra está mal. Quiero llegar a que a veces el enunciado nos lleva a suponer y hay el ejercicio cuando estamos hablando de ingeniería y requerimiento es que si hay algo que nos da la más mínima posibilidad de mi viedad para lidar con. Claro, o sea, a mí me da por la atención que nadie buscó aclarar la letra conmigo, por ejemplo. Vamos por les de que el alcance del y están en comunicado el alcanceque, ahí aproveché mientras elaborado yo laboré también. Bueno, muchas gracias por la participación, vemos el jueves. Nos vemos.