UML Domine el lenguaje de modelado más utilizado en la actualidad

5. REQUERIMIENTOSY CASOS DE USO Para razonar sobre la noción de evolución de requerimientos, es fundamental com­ prender que estos no son fijos e inalterables, sino que están sujetos a constantes modi­ ficaciones, son flexibles. Cuando una estrategia de requerimientos nace ya concebida para manejar cambios, la evolución del sistema será mucho más sencilla de llevar a cabo. Especialmente en el contexto del software, los requerimientos tienden a cambiar, por lo que debemos adoptar una estrategia abierta, que contemple modificaciones. Los requerimientos no son independientes unos de otros, se relacionan. Algunos colaboran entre sí, mientras que otros entran en conñícto. Para el ejemplo de la heladera, requerimientos en conflicto serían el costo versus la fi.mcionalidad. Cuantas más funciones y versatilidad tenga la heladera, mayor será el costo. ¿Cómo resolvemos la situación? Compraremos la mejor heladera que podamos con el dine­ ro del que disponemos. Dentro del mundo del software sucede lo mismo. La efi­ ciencia de un sistema juega en contra de la facilidad de uso (y viceversa). La flexi­ bilidad atenta contra la seguridad (y viceversa), y así podemos seguir enumerando. Otro aspecto importante se refiere a la trazabilidad. A medida que el proyecto avan­ za, los requerimientos se plasman en modelos, y luego estos se codifican en alguna pla­ taforma y lenguaje de programación. Siempre que podamos identificar y unir cada por­ ción de código con el requerimiento que está implementando, tendremos la posibili­ dad de modificar y evolucionar nuestro sistema con mucha mayor rapidez y precisión. Finalmente, debemos lidiar con la asignación de prioridades a los requerimientos. Como vimos en las secciones previas, no todos los requerimientos tienen la misma importancia. Saber distinguir cuáles son vitales y cuáles son sólo deseables para el sistema es central a la hora de dedicar recursos y esfuerzos para cada uno. En el momento de designar el mecanismo para establecer prioridades existen, al menos, dos posibilidades: numéricos y no numéricos. Los primeros establecen la calidad basándose en el orden de los niimeros naturales. En general, números más chicos representan más prioridad. Si aplicamos este mecanismo sobre la heladera, la canti­ dad de dinero disponible tendrá prioridad uno, mientras que el color tendrá prio­ ridad cinco. Los segundos se basan en escalas. Por ejemplo, podríamos clasificar todos nuestros requerimientos con la siguiente escala: esenciales, importantes y deseables. Bajo esta escala tendremos el color de la heladera en la categoría desea­ bles, mientras que el dinero o las medidas estarán clasificados como esenciales. m CAMBIOS EN EL SOFTWARE Los requerimientos constituyen la parte crítica de cualquier sistema de software. Dada su natura­ leza de constantes cambios, es fundamental que todos los procesos de desarrollo contemplen esta característica de manera tal que el software resultante sea lo más adaptable a cambios como sea posible. La utilización de casos de uso es una técnica que ayuda a validar cada uno de ellos. 140