Ingeniería de requerimientos necesidades y buenas prácticas

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

Resumen

La sesión se centra en la ingeniería de requerimientos, diferenciando claramente entre identificar una necesidad o problema del dominio y proponer una solución anticipada. Se enfatiza que las necesidades surgen de dolencias, incertidumbre y fricciones en el dominio del sistema, y que no deben confundirse con soluciones. Se clasifican los requerimientos en funcionales y no funcionales; estos últimos describen el 'cómo' y se relacionan con atributos de calidad como funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Se destaca la importancia de declarar los requerimientos de forma no ambigua, con características como factibilidad, y de evitar preguntas que induzcan soluciones en encuestas o cuestionarios. Como buenas prácticas se mencionan la elaboración de un documento de especificación de requerimientos y el uso de prototipos para validar con el cliente, facilitando la comprensión de artefactos técnicos. Finalmente, se anuncia que la próxima clase se profundizará en la actividad de elicitación, incluyendo encuestas, entrevistas e ingeniería inversa.

Puntos clave

• No es lo mismo identificar una necesidad que tener en mente una posible solución; confundirlas lleva a productos sin valor diferencial.
• Las necesidades del dominio incluyen dolencias, incertidumbre y fricciones que impiden alcanzar un objetivo.
• Los requerimientos se clasifican en funcionales y no funcionales; estos últimos definen el 'cómo' y son atributos de calidad.
• Los requerimientos no funcionales deben tener 'nombre y apellido', es decir, ser medibles y específicos, evitando ambigüedades como 'el sistema debe ser rápido'.
• Los principales atributos de calidad son funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad, y se desglosan jerárquicamente.
• Buenas prácticas: documento de especificación de requerimientos y uso de prototipos para validar con el cliente.
• La próxima clase se iniciará la actividad de elicitación, viendo encuestas, entrevistas e ingeniería inversa.

Transcripción

Bueno. Aprovechando esta, la siencialidad que no es tan usual, es en la fizarra de verdad. Esa si pié, es genial. Bueno. Ah, gracias por el segundo, el otro. De hecho, de hecho, de hecho, me bajaba el pie a decir algo importante. Bueno, para mí es importante, pero para mucha gente no. ¿Qué? no sé qué es la verdad ¿Qué pasa? Que en dominio el problema tenemos necesidades, dolencias, insetidumbre, etc. ¿Verdad? Entonces, ¿Quién me puede decir ejemplos de esto? Inceptidum. A mi manera. ¿Qué es esto? pero cuál es el problema? que a veces estamos viciados con una imaginación muy grande y ya nos imaginamos que esto y eso nos hace ruido momento de tratar de identificar esto. ¿Sí? Entonces ¿Qué ocurre acá? Y con qué quiero que nos quedemos. No es lo mismo identificar una necesidad que tener la cabeza una posible solución a una necesidad. Entonces yo les había dado un ejemplo de por lo menos de una persona que tenía problemas con. Contaba con los gastos registra y ya. Entonces qué pasa. En este, había una fricción, ¿no? Una fricción que le impedía alcanzar algo, que en este caso puntual era poder tener un registro de sus gastos, ¿no? Entonces, ¿qué pasa? Que si nosotros estamos analizando un problema, no podemos llegar y decirle, bueno,, se excelen". Porque es lo que se nos viera la mente, porque es lo que nos hace sentido, porque hay otras variables a considerar. Y eso es lo que va a hacer que nosotros tengamos un producto que aporte valor y que no sea otra cosa más el montón. Entonces, no es lo mismo decir "Bueno, yo necesito registrar mis gastos". A decir, decir necesito registrar mis gastos, pero en este proceso tengo determinada fricción o tengo determinada incertidumbre y ahí va a valer la pena hacer el trabajo de aplicar encuestas, cuestionarios y todo esto., las necesidades vienen siendo parte del domino del sistema. ¿Cuáles eran? Funcionales y no funcionar. ¿Y qué es que hay cada uno? Esto qué era y esto qué era? y los no funcionarles en el concierto entonces el peque ya entendí todo esto voy a poder describir que y cómo del sistema para dar solución a eso insisto rotundamente querer entender esto con esto de forma pre dispuesta en la cabeza está mal y fíjense que pasa mucho sobre todo como estamos haciendo un cuestionario que en vez de o en puestas que en vez de hacer preguntas que investiguen estas cosas hacen preguntas como precieron formulario un p?" Eso es solución, eso todavía no es lo que nos interesa. Igual cuando veamos el tema de esta situación lo vamos a profundizar un poco más. ¿Qué ocurre con esto de los requerimientos, funcionales y no funcionales? Claramente como se supone que el sistema tiene que obedecer esa declaración que está allí tendría que estar escrita de cierta forma para evitar cosas como ambigüedades. Es un poco lo que pasaba cuando Julieta les pedía que hiciera un dibujo y no salió también al principio. Pero bueno, después de este review. de no tendrían que generarnos más preguntas y requerimientos no funcionales que ya sabemos que es el como tenemos ejemplos como el sistema de soportar mil usuarios realizando un pedido en forma simultánea sin una degradación del tiempo de respuesta mayor a cinco segundos por ningún paso. A mí me gusta llamarlo que los requerimientos no no funcionan tienen que tener nombre y apellido y esto es porque supongamos que yo les quiero algo como esto. es rápido eso esto. ¿Qué tendrían que hacer ustedes en este caso? El sistema debe ser rápido, dice. Entonces, si ustedes están relevan información y en su cabeza los requinamientos tienen que hacer algo así, pero a ustedes les van a dar esto porque lo ingenieró en el sistema y que se han de requerimiento con ustedes, en los clientes, la mayoría de los casos. Entonces, ¿qué harían ustedes al momento de que les digan esto. preguntar o incluso proponer ¿No? ¿Pueden decirle a ustedes mismos? Un segundo está bien. Y si o no. No me acuerdo si esto fue con la mañana con ustedes pero yo intenté abrir esto y no abría. ¿Esa fue como ustedes? Sí. Vamos a ver si tiene más suerte. ¿Qué pasa? Según estáis hoy, 5 mil vamos a tener una agrupación de requerimientos no funcionales que van a ser jerárquicos y se van a ir desglosando. Los principales son funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Y cada uno de ellos tiene adentro, más. De vuelta, fíjense que todo esto no nos está diciendo que va a ser el sistema, sino que nos está diciendo el como y por eso se les suele relacionar con atributos de calidad. ¿Sí? Que un poco lo que les comentaba esa clase, ¿no? Que podemos tener los sistemas que hacen lo mismo, por ejemplo, una transferencia, pero si uno lo hace más rápido que otro, el como lo hace es lo que genera diferencial. Buenas prácticas. Ten atención a esto porque que es donde nos ponemos más observadores al momento de correcir el obligatorio. Pero si estamos hablando de que los requerimientos los tenemos que declarar de forma tal, de evitar ambigüedad. Eso quiere decir que tendríamos que tratar de identificar qué características pueden tener esa declaración para asegurarnos de que todos los requerimientos que escribamos los cumplan. Y eso lo tenemos acá. que esto de la factibilidad que ya esto no nos habla tanto de que lo hayamos declarado o especificado bien sino que nos habla de que el requerimiento tenga sentido ¿sí? porque porque si estamos trabajando en un equipo que tiene dos programadores nada más y tenemos un requerimiento gigante que tenemos que traer mañana no da, no es factible por más que lociquemos y lo escribamos de una manera perfecta. Entonces, estas características no las voy a aprofundizar mucho más porque les voy a proponer algo más tarde para que lo revisen y lo retomamos. Parte Pueve. Parte de las buenas prácticas al momento de declarar requerimientos es tener un documento de especificación. Esto como documento pasaba mucho más cuando trabajaban con metodología tradicionales. Ahora en AGI se tienen, digamos, plataformas y se tiene cierta forma de organizar los requerimientos. Pero lo importante es poder tener una estructura en la cual tengamos los requerimientos declarados, especificados, priorizados y analizados. Eso igual vamos a ver cuando estemos estudiando las otras actividades del proceso ingenieria y requerimiento. Que se acuerda que eso también lo hablamos, vimos la diferencia de hablar de requerimientos como artefactos y vimos el proceso como tal dentro del ciclo de vida de ingeniería y requerimiento. Otra buena práctica es hacer prototipos. ¿Por qué? Porque si bien es cierto que nosotros vamos a tener una lista de requerimientos funcionales y no funcionales, al momento de querer validar esos requerimientos con nuestro potencial usuario, nuestro cliente, tener un prototipo, una representación gráfica de su requerimiento, va a facilitar la comprensión del cliente. Porque al final del día, los requerimientos son un artefacto técnico que ustedes conocen porque están estudiando esto pero el cliente en elisariamente no. Bien, eso está ahí. Entonces ya estábamos hablando de lo que era el proceso de ingeniería de requerimientos como tal y teníamos estas cuatro actividades. Estas cuatro actividades la vamos a tener que hacer ustedes Entonces, vamos a prestar la atención. La próxima clase vamos a comenzar con esta actividad que es elitar ahí donde vamos a ver el tema de las encuestas, el tema de otro estrategias como las entrevistas, la ingeniería inversa que es lo que yo les dije desde hace varias semanas atrás que podían ir comenzando. Ehh. Y ta seguimos la próxima clase porque no tuvieron recreo. Bueno, gracias por quedarse. Nos vemos el jueves.