Obtención de requisitos

  • Jordi Pradel Miquel

    Jordi Pradel Miquel

    Ingeniero de Informática por la Universidad Politécnica de Cataluña. Socio fundador e ingeniero de software en Agilogy, profesor en el Departamento de Ingeniería de Servicios y Sistemas de Información de la UPC, consultor de los Estudios de Informática y Multimedia en la Universitat Oberta de Catalunya y miembro del Grupo de Investigación de Ingeniería del Software para Sistemas de Información de la UPC, en el que ha publicado varios artículos de investigación en el campo de la ingeniería del software y de la aplicación a sistemas de información.

  • Jose Raya Martos

    Jose Raya Martos

    Ingeniero de Informática por la Universidad Politécnica de Cataluña. Compagina su actividad como ingeniero de software en Agilogy (empresa de la cual es socio fundador) con la de consultor en el Área de Ingeniería del Software en la UOC y la de profesor a tiempo parcial en el Departamento de Ingeniería de Servicios y Sistemas de Información de la UPC. A lo largo de los años ha trabajado en proyectos de sectores varios, como el financiero, la Administración pública o las telecomunicaciones, ejerciendo tareas técnicas y de gestión, lo que le ha dado una amplia perspectiva sobre el mundo del desarrollo de software y de su diversidad.

PID_00191249
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-Compartir igual (BY-SA) v.3.0 España de Creative Commons. Se puede modificar la obra, reproducirla, distribuirla o comunicarla públicamente siempre que se cite el autor y la fuente (FUOC. Fundació per a la Universitat Oberta de Catalunya), y siempre que la obra derivada quede sujeta a la misma licencia que el material original. La licencia completa se puede consultar en: https://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca

Introducción

El primer paso para obtener los requisitos de un sistema es identificar lo que denominamos requisitos candidatos: todos aquellos requisitos que alguno de los stakeholders querría que nuestro sistema cumpliera.
En las asignaturas previas, ya hemos visto algunas técnicas para obtener los requisitos de un sistema, como el modelado de roles de usuario o las entrevistas y cuestionarios, pero aún no hemos entrado en detalle por lo que respecta a algunos de los problemas importantes de la identificación de requisitos.
Uno de los problemas que nos encontramos a la hora de llevar a cabo esta tarea es descubrir los requisitos que aún no conoce nadie. Esto es debido a que, a veces, se nos hace difícil describir cómo queremos que sea el sistema final que aún no hemos podido ver ni tocar. Por eso será importante que tengamos en cuenta algunas técnicas para descubrir estos requisitos que, a priori, nadie sabía que existían.
Otro problema que estudiaremos es la relación de nuestro sistema con sistemas o componentes preexistentes. A veces, el hecho de que haya una solución previa a alguno de los problemas que queremos resolver con este sistema nos obligará a hacer un estudio de compatibilidad entre nuestros requisitos y los del sistema que queremos integrar, para ver si esta integración es posible o no.
Finalmente, hablaremos sobre el modelado de objetivos. Recordemos que los requisitos del sistema están muy relacionados con los objetivos que los diferentes stakeholders quieren alcanzar con el nuevo sistema y, por eso, tener correctamente estructurados e identificados estos objetivos nos ayudará a estructurar e identificar correctamente nuestros requisitos.

Objetivos

El objetivo principal de este módulo es dar a conocer al estudiante un conjunto de herramientas que lo ayuden el proceso de obtención de requisitos para el desarrollo de software. En concreto, al finalizar este módulo, el estudiante debe ser capaz de:

  1. Conocer las principales técnicas de obtención de requisitos.

  2. Conocer técnicas para descubrir requisitos que los stakeholders aún no saben que tienen.

  3. Saber evaluar el impacto sobre los requisitos de la existencia de una solución predefinida.

  4. Conocer la relación entre objetivos y requisitos, así como tener una idea muy básica de en qué consiste el modelado de objetivos.

1.Técnicas de obtención de requisitos

Como ya sabemos de asignaturas anteriores, la obtención de requisitos consiste en obtener la lista de todos los requisitos que, idealmente, habría de satisfacer el sistema que se desea desarrollar.
Denominamos requisitos candidatos a los requisitos obtenidos en esta primera etapa, ya que aún no hemos decidido si el sistema que se desea desarrollar los tiene que cumplir o no.
La técnica más básica para la obtención de requisitos es pedirlos a los stakeholders mediante el uso de algunas de las técnicas que comentaremos a continuación.

1.1.Brainstorming

El brainstorming (1) es una técnica de creatividad para grupos que favorece la generación de ideas de manera colaborativa. La técnica original establece cuatro reglas:
1) Priorizar la cantidad por encima de la calidad de las ideas.
2) Retrasar las críticas y centrarse en extender las ideas presentadas o en presentar otras nuevas.
3) No rechazar ideas inusuales.
4) Combinar y mejorar ideas.
También es muy importante tener muy clara cuál es la pregunta que tenemos que responder. Por ejemplo, si queremos identificar stakeholders potenciales y, para cada stakeholder, identificar requisitos candidatos, es mejor hacerlo en sesiones independientes que no en una misma sesión donde se intentan responder varias preguntas a la vez.
El proceso básico de brainstorming consiste en:
1) Crear el grupo de trabajo (intentando que sea lo más diverso posible para tener el máximo de puntos de vista).
2) Brainstorming inicial, donde se proponen tantas ideas como sea posible.
3) Organizar y consolidar el conjunto inicial identificando duplicidades.
4) Refinar y documentar la lista definitiva.

1.2.Modelado de roles de usuario

El modelado de roles de usuario es una técnica orientada a la identificación del tipo de usuario del sistema, que habitualmente se aplica en forma de brainstorming.
75593m2002.gif
La idea básica de esta técnica es que, en lugar de buscar los requisitos de todos los usuarios individuales del sistema, los podemos agrupar según el rol y asumir que todos los usuarios individuales que tienen el mismo rol ante el sistema tendrán requisitos parecidos.
Por ejemplo, en Viajes UOC podemos identificar el rol de usuario “Agente de viajes” y hacer la siguiente descripción:
“No es experto en informática, aunque tiene experiencia en el uso de Internet y de los sistemas de información de las centrales de reservas. Quiere poder consultar información sobre un destino, contratar viajes para sus clientes y poder aportar recomendaciones sobre los destinos.”

1.3.Entrevistas y cuestionarios

Esta es una de las técnicas más utilizadas para la obtención de requisitos. Consiste, obviamente, en entrevistarse con los stakeholders para obtener directamente de ellos los requisitos que tienen sobre el sistema que hay que desarrollar.
75593m2003.gif
Las claves para que la entrevista sea productiva son:
1) Elegir correctamente a los entrevistados
2) Evitar las respuestas condicionadas
3) Evitar respuestas limitadas por el conocimiento actual
4) Aportar información sobre el coste de las alternativas

1.4.Observación y prototipado

El prototipado consiste en construir un software con un aspecto similar al del producto final, aunque en su construcción, el objetivo principal es obtener algo lo más pronto posible al mínimo coste. Por eso, a menudo se usan herramientas y lenguajes de programación específicos para la creación de prototipos.
Lo que distingue un prototipo del producto final es que el prototipo se usa para recoger información sobre el uso del producto pero nunca se aprovecha nada de la construcción del prototipo para la construcción del producto final.
El prototipado, sin embargo, presenta dos inconvenientes importantes: por un lado, el coste de construir un prototipo no es trivial y, por el otro, puede dar una falsa sensación de producto final (a veces es difícil justificar que se tardará seis meses en tener implementada una funcionalidad que el cliente “ha visto” funcionar).
Por todo lo cual, la experimentación se hace, a menudo, con modelos de la interfaz o maquetas.
La principal ventaja de las maquetas es que son más baratas de hacer que un prototipo, ya que no se detalla el aspecto visual de las pantallas (ya menudo, como en el ejemplo de la figura, se simulan estas pantallas con un dibujo a mano alzada).
75593m2004.gif
Otra ventaja de las maquetas es que son un elemento de comunicación muy útil, ya que no hay que estudiar ninguna notación concreta y, por tanto, la pueden usar tanto los stakeholders y responsables de producto, como los diseñadores gráficos o los desarrolladores.
En algunos entornos ágiles (por ejemplo, empresas “start-up” de Internet), incluso se utilizan las maquetas como elemento principal de comunicación de los requisitos en un ciclo de desarrollo similar a este:
1) Se crea una maqueta de la funcionalidad que se quiere implementar.
2) Se distribuye la maqueta a los stakeholders y se recoge su impresión.
3) Se implementa la funcionalidad y se añade al incremento del producto correspondiente a la iteración actual.
La ventaja de este tipo de ciclo de vida es que permite adaptarse rápidamente a los cambios en los requisitos, ya que el tiempo que pasa entre que se decide implementar una funcionalidad y que se implementa es muy pequeño.

1.5.Listas predefinidas

Otra técnica es la de utilizar listas predefinidas de requisitos que nos pueden ayudar a no pasar por alto algunos requisitos que son habituales en la mayoría de sistemas.
75593m2005.gif
Esta técnica es especialmente útil para los requisitos no funcionales, ya que, como hemos visto anteriormente, estos son independientes del comportamiento del sistema.
El estándar IEEE-830 incluye una de estas listas. Otra plantilla con una lista predefinida de requisitos no funcionales es la plantilla Volere.

2.Descubrimiento de requisitos

A menudo los stakeholders no están en condiciones de proporcionarnos todos los requisitos porque es muy difícil imaginarse cómo será el producto final a partir de una descripción abstracta del mismo.
Además, las propias necesidades que queremos satisfacer pueden cambiar con el uso del software. Por eso necesitamos herramientas que nos permitan simular el uso del software sin tener que desarrollarlo completamente.
IKIWISI (I’ll know it when i see it) es el término que, a menudo, se usa para hacer referencia al hecho de que no podemos describir qué es lo que queremos, pero que, si nos lo ponen delante, lo podemos reconocer como aquello que queríamos.
La experimentación es una herramienta básica para el descubrimiento de requisitos no sospechados. En este sentido, las técnicas más tradicionales son el prototipado y la modelización de la interfaz gráfica de usuario.
Para llevar a cabo esta tarea, necesitamos encontrar el modo de simular el uso del sistema para que aparezcan estos requisitos y experimentar con maneras alternativas de implementar una misma funcionalidad.
También necesitaremos determinar qué alternativas pueden ser más interesantes de probar y poderlas probar con el mínimo coste posible (en tiempo y dinero).

2.1.Innovación en los procesos

Si queremos que el nuevo sistema que estamos desarrollando mejore la manera de funcionar de la organización para la cual lo desarrollamos, es necesario que este incluya un cierto componente de innovación: tenemos que encontrar nuevas maneras de trabajar que sean mejores que las existentes.
De hecho, los productos más exitosos son aquellos que consiguen “crear” una nueva necesidad. Por ejemplo, en el año 2004 casi nadie decía “ojalá que alguien inventara las redes sociales para poder compartir información con los amigos y familiares”. De hecho, todo el mundo pensaba que tenía esta necesidad más o menos cubierta con el correo, blogs, grupos, etc. En cambio, sólo 6 años después, en el 2010, la red social Facebook contaba con más de 500 millones de miembros.
“Nuestro trabajo es dar al cliente, dentro del plazo y el coste, no lo que quiere sino lo que nunca había soñado que querría; y cuando lo tiene delante, lo reconoce como aquello que siempre había querido”. (Denys Lasdun, 1965)
Antes de experimentar con alternativas, necesitamos un criterio para descubrir cuáles son las que nos pueden interesar en un sistema concreto. Algunos de los criterios que podemos aplicar son los siguientes:
1) Innovar en el servicio. Una de las formas básicas de innovación es ofrecer un servicio que, hasta ahora, no se estaba ofreciendo. El caso más típico es la automatización de alguna de las tareas manuales. Para innovar en el servicio nos tenemos que preguntar “¿qué puedo hacer por mis usuarios que hasta ahora no se esté haciendo por ellos?”.
En el caso de Viajes UOC, un ejemplo de este tipo de innovación sería el de poder compartir el plan de viaje con amigos y familiares. El hecho de saber que, contratando con Viajes UOC, los amigos y familiares del cliente tendrán acceso a la información (y teléfonos de contacto) del lugar donde se encuentran durante el viaje es una cosa que muchos de los clientes podrían estar haciendo por sí mismos (creando un documento con el resumen de la información y enviándolo a amigos y familiares) y que, al mismo tiempo, podría no haberse comentado durante las entrevistas.
2) Ofrecer más información. Cada vez más, las personas estamos acostumbradas a tener mucha información disponible y, con el paso del tiempo, cada vez demandamos más información.
En el caso de Viajes UOC, podemos ofrecer más información sobre los destinos (tal y como nos han pedido a las entrevistas) pero también tenemos otras oportunidades para dar más información a los clientes: por ejemplo, podemos dar información sobre disponibilidad de plazas en los vuelos y en los hoteles, o sobre el estado de confirmación de las reservas de su viaje.
3) Fomentar la participación. Una de las ventajas de dar más información a los usuarios es que, de este modo, ayudamos a hacerlos participar del proceso que se está llevando a cabo. En esta línea, muchas empresas han basado su modelo de negocio en hacer participar a los clientes en alguno de los procesos que antes eran parte del trabajo del proveedor; un ejemplo de este tipo de innovación son aquellos vendedores de equipos informáticos que ofrecieron por primera vez la posibilidad de configurar a medida el equipo que se quería comprar.
Viajes UOC puede, con el nuevo sistema, hacer que el grado de participación del cliente en la organización de su viaje sea mucho más alto que en el modelo tradicional de la agencia, hasta el punto de que el cliente podría configurar todo el viaje desde casa e ir a la agencia sólo a confirmar el pedido.
4) Ofrecer alternativas. También puede ser útil pensar en nuevas alternativas a los procesos actuales, como por ejemplo nuevos canales de interacción (por teléfono, por el móvil o por Internet), de manera que los usuarios puedan decidir de qué modo quieren interactuar con nuestra organización en cada momento.
En el caso de Viajes UOC, hasta ahora toda la comunicación con los clientes se hacía de manera presencial o, como mucho, telefónica. El nuevo sistema está ofreciendo una nueva alternativa: relacionarse con los clientes a través de Internet.
5) Considerar el caso de uso completo. ¿Qué hacía la persona que ha puesto en marcha un caso de uso en el momento de decidir que quería ponerlo en marcha? Esta pregunta nos puede llevar a identificar nuevas oportunidades de mejora del servicio, puesto que, al considerar el caso de uso desde esta perspectiva, es más fácil que identifiquemos oportunidades para innovar en el servicio.
James Robertson explica, en su artículo de 2002 “Eureka! Why Analysts Should Invent Requirements”, el caso de una compañía aseguradora que, cuando algún cliente tenía un siniestro con el coche, enviaba al momento un perito al lugar del accidente que se encargaba de evaluar los daños y (si el cliente quería) de extender un cheque allí mismo por el valor de los mismos. En este caso, pensar en lo que hacía el cliente que estaba informando de un accidente les llevó a simplificar los trámites, hasta el extremo de que, según cómo, ya no hacía falta que el cliente accediera al sistema para informar sobre el accidente.
Otro ejemplo interesante que propone [Robertson] es el de los enlaces afiliados de Amazon. Amazon pensó en lo que hacían sus clientes en el momento de decidir que querían comprar un libro (o cualquier otro producto) y por eso crearon el programa de enlaces afiliados, de manera que la web donde se hablaba del libro ofreciera directamente la compra del mismo.

3.Soluciones preexistentes

Cada vez es más habitual la utilización de soluciones preexistentes durante el desarrollo de software. Un ejemplo es la utilización de componentes de software COTS (commercial off-theshelf). En este caso, el producto a desarrollar no se crea de cero, sino que se parte de subsistemas ya implementados.
El software COTS es software que ya está desarrollado y se encuentra disponible en el mercado de manera que se puede usar directamente.
También es habitual encontrar este software disponible en forma de servicio (típicamente un servicio web). En este caso, se puede hablar de Platform as a Service (PaaS), Infrastructure as a Service (IaaS) o Software as a Service (SaaS) según si lo que contratamos es una plataforma de ejecución, un componente de infraestructura (cómo, por ejemplo, la base de datos relacional) o un sistema de software completo.
Un servicio es una actividad en la que una parte ofrece a otra, de modo que el contratante obtiene acceso a una serie de bienes, personas, instalaciones, etc. sin adquirir su propiedad.
Un servicio no es un componente de software que adquirimos y ejecutamos en nuestras instalaciones sino que es un sistema autónomo, que se ejecuta en las instalaciones de la organización que lo ofrece y al cual accedemos de forma remota, normalmente por Internet. Una de las ventajas de los servicios es que no nos tenemos que preocupar de su mantenimiento ni del de los ordenadores sobre los que se ejecuta.
Por ejemplo, Viajes UOC necesitará tener una base de datos de hoteles. El primer escenario que nos viene a la cabeza ante esta situación es aquel en el que Viajes UOC “compra” un sistema gestor de bases de datos Relacionales (SGBDR) y, sobre este sistema, desarrolla la funcionalidad necesaria para gestionar la información relativa a los hoteles.
Podría pasar, sin embargo, que el SGBDR no pudiera satisfacer alguno de los requisitos de nuestro sistema (como por ejemplo, que se considerara que la disponibilidad de esta información es más importante que la consistencia) y decidiéramos usar otro tipo de sistema de base de datos o, incluso, implementar uno propio.
También se podría considerar contratar un servicio de base de datos (relacional o no) a un proveedor externo o, incluso, contratar un servicio con información sobre hoteles, de forma que Viajes UOC no tuviera que mantener esta información actualizada.
Ya sea el caso de la compra de un producto de software como el de la contratación de un servicio, el impacto sobre los requisitos será similar: en los dos casos habrá que compatibilizar los requisitos del sistema que estamos desarrollando con los requisitos para los cuales se desarrolló la solución que queremos adoptar.
El impacto, por lo tanto, será en los dos sentidos: por un lado, habrá que tener en cuenta los requisitos del producto a desarrollar a la hora de elegir una solución y, por otro, si no se encuentra una solución que cumpla los requisitos del producto a desarrollar al 100%, habrá que adaptar el producto a aquello que las soluciones nos ofrezcan.
Un ejemplo un poco extremo sería aquel en el que queremos procesar una reserva de viaje en menos de un segundo, pero ninguna de las soluciones disponibles permite procesarla en menos de dos segundos. En este caso, es muy probable que nosotros no seamos capaces de superar este tiempo y, por lo tanto, haya que revisar el requisito o, incluso, descartarlo si lo consideramos imposible de satisfacer.
Es por este motivo por lo que las metodologías de evaluación de alternativas acostumbran a incluir un apartado donde se revisa la adecuación del software a las necesidades de nuestro producto y por el cual, a menudo, habrá que estimar el coste de integración de la solución para compararlo con el coste de desarrollo.
Supongamos que Viajes UOC quiere ofrecer la posibilidad de mostrar fotografías de los hoteles hechas por los viajeros en la ficha de detalle. Se quiere que los clientes de Viajes UOC puedan publicar fotografías que ellos hayan hecho de los hoteles y que otros clientes las puedan ver. Más concretamente, se ofrecerá a los clientes, en la ficha de detalle de un hotel, la posibilidad de publicar una o más fotografías que haya hecho en alguna de sus estancias en el hotel (con independencia de que hubiera contratado el viaje con Viajes UOC o no).
Ante esto se tendrán que evaluar varias posibilidades. Por un lado, podemos desarrollar íntegramente el servicio de almacenamiento de fotografías y almacenar las fotografías en nuestros servidores. Habrá que desarrollar la funcionalidad de publicar una foto, ver una foto y borrar una foto. Habrá que tener en cuenta aspectos relativos a la privacidad de las fotos y los volúmenes de datos que pueden generar todas estas fotos.
Una alternativa, sin embargo, podría ser usar un software de “galería de fotos” que ya esté desarrollado (COTS). En este caso, habrá que ver si este software nos permite que un usuario publique una foto sin tenerse que identificar de nuevo en el sistema, o bien si se puede asociar una galería diferente en cada hotel, etc. De los diferentes productos disponibles en el mercado, intentaremos elegir aquel que más se acerque a la funcionalidad que hayamos desarrollado y que menos personalización requiera.
Por último, nos podríamos plantear contratar este servicio con un proveedor externo que ya esté ofreciendo esta funcionalidad. Se tendrán que valorar aspectos como el coste de alquilar este servicio (frente al coste de asumirlo nosotros) o bien si se puede dar el servicio manteniendo la imagen de marca de Viajes UOC, etc. Además, habrá que tener en cuenta otros factores, como por ejemplo qué pasa si el proveedor del servicio desaparece del mercado, etc.

3.1.Selección de componentes

Hay muchas metodologías de selección de COTS, también aplicables a la selección de servicios. La mayoría siguen una serie de actividades en común:

  • Definir el criterio de evaluación sobre la base de los requisitos del sistema a desarrollar.

  • Buscar productos y servicios candidatos.

  • Filtrar la lista de candidatos sobre la base de requisitos irrenunciables (aquellos que no son negociables).

  • Evaluar los candidatos restantes según los criterios definidos.

  • Analizar y evaluar los resultados del paso anterior y selección del producto o servicio más adecuado.

  • Personalizar el servicio o producto para reducir las diferencias respecto de los requisitos del sistema a desarrollar.

En muchos casos, estas actividades se pueden llevar a cabo de forma iterativa para refinar los criterios después de un primer ciclo de evaluación, y obtener en cada iteración una lista más refinada de productos o servicios candidatos.
Como se puede ver, durante la definición de los criterios de evaluación, se trata de definir qué requisitos son irrenunciables y cuáles son interesantes pero no imprescindibles, de cara a evaluar, más adelante, los productos y servicios.
Supongamos, por ejemplo, que queremos escoger una plataforma de desarrollo de aplicaciones para teléfonos móviles para desarrollar la versión móvil de Viajes UOC. Lo primero que deberemos hacer es definir qué criterios de evaluación se aplicarán.
Supongamos que tenemos un requisito político irrenunciable que la plataforma utilizada tiene que ser de código abierto. Algunos otros requisitos pueden ser que sea madura, con un grado de adopción elevado, que esté en desarrollo activo, que esté muy documentada, que sea portable, que soporte el envío de mensajes SMS, etc.
A partir de aquí, hay que buscar una lista de productos o servicios candidatos y descartar los que no cumplen los requisitos mínimos.
Siguiendo con el ejemplo anterior, el siguiente paso sería buscar plataformas de desarrollo de aplicaciones móviles. De estas, ya sea durante la búsqueda o en un paso posterior, se descartarían aquellas que no sean de código abierto, puesto que se ha decidido que este es un requisito irrenunciable.
El siguiente paso consiste en evaluar a los candidatos restantes. Para lo cual, puede ser útil crear una plantilla de evaluación; es decir, una plantilla donde puntuar el producto o servicio desde el punto de vista de cada requisito.
Para la selección de la plataforma de desarrollo, podemos crear una plantilla de evaluación consistente en puntuar cada requisito según unas categorías. Así, podríamos escribir, en nuestra plantilla:
Apoyo para el envío de SMS:

  • No soportado: 0 puntos

  • Soportado a través de una librería de terceros: 1 punto

  • Soportado de forma integrada: 2 puntos

De este modo, cada plataforma candidata se puede puntuar con 0, 1 o 2 puntos en cuanto al requisito de envío de SMS.
Una vez evaluados los candidatos, hay que hacer el análisis de los resultados y la selección del candidato más adecuado. Para lo cual habrá que ponderar el peso de cada requisito, puesto que algunos requisitos pueden ser más importantes que otros, y dar un valor total a cada candidato. Este proceso puede ser automatizado y formal pero también se puede hacer manualmente y teniendo en cuenta criterios cualitativos y menos formales.
En nuestro ejemplo, una plataforma concreta puede tener un 1 en cuanto a apoyo de envío de SMS, un 1 en madurez, un 2 en cuanto a la documentación, etc. Dando un peso específico a cada requisito podríamos obtener una puntuación total con la cual elegir la plataforma que más nos conviene. O, de forma menos automatizada, podríamos estudiar los resultados y tomar una decisión que no se base en un total calculado sino al razonar sobre estos resultados.
Finalmente, nos tendremos que plantear la posibilidad de modificar el servicio o producto seleccionado para reducir las diferencias respecto de los requisitos originales.
En el caso anterior, si hemos escogido un producto que no soporta directamente el envío de mensajes SMS, consideraremos la posibilidad de desarrollar alguna extensión o plugin para añadir esta capacidad.

4.Objetivos y requisitos

Otra técnica que nos puede ayudar a descubrir requisitos es la descomposición de objetivos. Para entender esta técnica, es importante que entendamos la relación entre objetivos y requisitos y que seamos capaces de organizar correctamente los diferentes objetivos.

4.1.Relación entre objetivos y requisitos

Un objetivo es algo que un stakeholder quiere conseguir del software a desarrollar.
Un requisito es una característica observable del software a desarrollar que satisface o ayuda a satisfacer un objetivo de un stakeholder.
De todas las posibles características observables del software, sin embargo, sólo tendremos en cuenta como requisitos candidatos aquellas que satisfagan el objetivo de un stakeholder o ayuden a conseguirlo. Por lo tanto, en muchas ocasiones, hay una relación de uno a uno entre requisitos y objetivos, puesto que, a menudo, un requisito es la característica observable que satisface el objetivo.
A veces, sin embargo, un objetivo va más allá delo que podemos observar en un software. Algunos objetivos sólo se pueden satisfacer si las personas, organizaciones u otros sistemas de software más allá del que analizamos también colaboran positivamente.
Por ejemplo, el Departamento de Marketing de Viajes UOC tiene un objetivo: consolidar el valor de la marca. Esto, sin embargo, no es un requisito del sistema puesto que el sistema no puede, por sí mismo, consolidar el valor de la marca, ya que para conseguirlo hará falta que otras personas, departamentos y sistemas colaboren; se necesitará, por ejemplo, que se haga publicidad de la marca, que los viajes que se vendan estén muy considerados, etc. En todo caso, el sistema puede satisfacer ciertos requisitos que ayuden a lograr este objetivo.
Otros objetivos pueden incluir varios requisitos en cuanto que habrá varias características observables que ayudan a satisfacerlos.
Si decimos que “Como cliente de Viajes UOC quiero comprar un viaje”, estamos expresando un objetivo (comprar un viaje), que dará lugar a uno o más requisitos (poder indicar las fechas en las que se quiere viajar, conocer los hoteles disponibles en la zona en aquellas fechas, etc.).
Podemos ver, pues, que la diferencia entre objetivos (aquello que los stakeholders quieren de nuestro sistema) y los requisitos (aquella cualidad que nuestro sistema tiene que satisfacer) es, a veces, difícil de encontrar. No se trata, pues, de intentar diferenciar de forma estricta entre unos y otros, sino de tener un marco general por el cual usar el término más adecuado en cada caso.
De hecho, algunas técnicas de documentación de requisitos como las historias de usuario o los casos de uso incluyen la descripción del objetivo en la descripción del requisito. En este contexto, el objetivo es un resultado concreto que alguien espera obtener de nuestro sistema.
En general, podemos decir que el objetivo es el que determina la relación entre el stakeholder y nuestro sistema. Por eso nos puede ser útil pensar en términos de objetivos a la hora de obtener los requisitos candidatos: si identificamos correctamente los objetivos, nos será más fácil descomponerlos en subobjetivos que nos determinen nuevos requisitos.
En el ejemplo anterior, el objetivo de satisfacer el valor de la marca de Viajes UOC se puede descomponer en objetivos más concretos, como, por ejemplo, “Respetar la imagen corporativa de Viajes UOC” (que sí que es una propiedad que el sistema puede satisfacer).
Desde el punto de vista opuesto, “Poder crear ofertas exclusivas de una agencia” es un requisito candidato que nos aleja del objetivo de “consolidar el valor de la marca” y, por lo tanto, tener claro el objetivo nos puede ayudar a identificarlo como requisito a descartar.
Identificar los objetivos, además, nos puede ser útil más adelante, durante la priorización y selección de requisitos, puesto que nos permitirá saber qué stakeholders están relacionados con cada objetivo.

4.2.Organización de los objetivos

Hemos visto que los objetivos se pueden descomponer en subobjetivos, desde los más generales (como “Consolidar el valor de la marca”) hasta los más concretos (como “Introducir el nombre del hotel”). Es habitual que, al describir su visión del sistema, las personas salten de un nivel a otro sin darse cuenta. Por eso, es importante que, al identificar los objetivos, sepamos distinguir cuáles son del mismo nivel y cuáles no y así podamos estructurar mejor nuestra descripción.
75593m2008.gif
Por ejemplo, analicemos el siguiente texto:

“Queremos consolidar la presencia internacional de nuestra empresa. Por eso, habrá que adaptar el sistema de información de venta de viajes y hacer que, entre otras cosas, cuando un cliente de un país de fuera de la zona euro compre un viaje y quiera ver el precio total, el sistema calcule automáticamente la conversión entre divisas. Los desarrolladores nos han dicho que crearán una tabla en la base de datos con la cotización más reciente de la divisa del país”.

Este es un caso típico de descripción que mezcla objetivos muy generales con objetivos concretos e, incluso, con parte de la descripción de la solución.
“Crearán una tabla en la base de datos con la cotización más reciente de la divisa del país” no nos está describiendo el problema sino la solución, por lo que de momento podemos ignorar esta frase ya que nos está limitando el conjunto de soluciones posibles.
En cambio, “Queremos consolidar la presencia internacional de nuestra empresa” o “el sistema calcule automáticamente la conversión entre divisas” sí que forman parte del espacio del problema que tenemos que resolver, a pesar de encontrarse en niveles de concreción muy diferentes.
Podemos distinguir tres niveles básicos de objetivos:

  • Objetivos generales: expresan por qué tenemos que desarrollar el producto.

  • Objetivos de usuario: expresan qué esperan los usuarios de nuestro sistema.

  • Objetivos de tarea: expresan qué tareas tienen que llevar a cabo los usuarios para conseguir los objetivos de usuario.

Más concretos que los objetivos de tarea sólo quedan las decisiones de diseño y arquitectura, que, al formar parte de la solución y no de la descripción del problema, no forman parte de los requisitos del sistema.
4.2.1.Objetivos generales
Los objetivos generales se caracterizan por el hecho de que pueden afectar a más de un sistema de información. Lo más habitual es que tardemos días, semanas o incluso años en lograr estos objetivos una vez que hemos iniciado el proceso.
En nuestro ejemplo, podemos identificar algunos de estos objetivos, como, por ejemplo, “Expandir la franquicia de 95 a 200 agencias en dos años” o “Consolidar el valor de la marca en los mercados emergentes”. En los dos casos se trata de objetivos muy generales que habrá que descomponer (especialmente el segundo, ya que, tal y cómo está descrito, no se puede determinar si se ha logrado o no).
“Expandir la franquicia de 95 a 200 agencias en dos años” se puede descomponer en objetivos más concretos para nuestro sistema de información, como por ejemplo que tiene que soportar 600 usuarios concurrentes (3 por agencia) o bien, si estas agencias trabajaran en diferentes países, soporte de diferentes divisas, más de un idioma, etc.
Algunos de los objetivos generales de la organización darán lugar a requisitos funcionales, mientras que otros darán lugar a requisitos no funcionales.
El departamento financiero tiene un objetivo, que es “Recuperar la inversión en menos de dos años”. Esto no se puede trasladar a ningún requisito funcional, pero habrá que tenerlo en cuenta a la hora de definir el presupuesto del proyecto.
En cambio, el objetivo “Internacionalizar la empresa” puede dar lugar a requisitos funcionales, como por ejemplo “Pagar en una divisa diferente al euro”.
En cualquier caso, estos objetivos se tendrán que documentar en su propio documento (diferente de la especificación de requisitos) puesto que no todos formarán parte directamente de la compilación de requisitos de nuestro sistema de información.
4.2.2.Objetivos de usuario y de tarea
Los objetivos de usuario, en cambio, están muy relacionados con la funcionalidad que ofrece el sistema de información. Por este motivo, los objetivos de usuario acostumbran a convertirse en casos de uso o historias de usuario donde tenemos un actor principal (o un usuario en el caso de las historias de usuario) que quiere conseguir algo del sistema.
Por ejemplo, podemos considerar un objetivo de usuario el hecho de que un cliente quiera “comprar un viaje”. En este caso, es muy probable que tengamos un caso de uso denominado “Comprar un viaje”, donde el actor principal sea el cliente.
El objetivo de este caso de uso, a su tiempo, se puede descomponer en subobjetivos como: “Consultar la disponibilidad de vuelos”, “Consultar la disponibilidad de hoteles”, “Consultar las recomendaciones sobre un hotel”. Algunos de estos subobjetivos tienen un valor intrínseco más claro que otros.
“Consultar las recomendaciones sobre un hotel” es una cosa que el cliente puede querer hacer con independencia de si al final compra o no compra el viaje, mientras que “Consultar la disponibilidad de hoteles” es una cosa que cuesta más imaginar que quiera hacer si no es que realmente quiere comprar el viaje. En este sentido, decimos que “Consultar la disponibilidad de hoteles” tiene menos valor para el usuario que “Consultar las recomendaciones sobre un hotel”, lo cual lo sitúa más cerca del nivel de tarea.
Un caso más evidente de objetivo de nivel de tarea es “Introducir las fechas en las que se quiere hacer el viaje”. En este caso, es evidente que el cliente no querrá introducir las fechas en las que se quiere hacer el viaje si no es para conseguir algo más.
Los objetivos de usuario se pueden descomponer en subobjetivos que, o bien tienen un valor intrínseco para el usuario (y en este caso todavía los podemos considerar objetivos de usuario) o solo tienen valor dentro del escenario que lleva al usuario a conseguir su objetivo. Estos últimos los consideramos objetivos de tarea.
En cuanto a la duración temporal, los objetivos de usuario se acostumbran a satisfacer en minutos o, como mucho, horas, mientras que los de tarea serán más cortos puesto que un objetivo de usuario se logra mediante la suma de varios objetivos de tarea.
75593m2009.gif
4.2.3.Clasificación de objetivos
Podemos volver a analizar el texto con el que hemos empezado este apartado a la luz de esta clasificación:

  • “Consolidar la presencia internacional de nuestra empresa” es un objetivo general que puede tardar años en conseguirse y que no es un requisito de nuestro sistema (no le podemos pedir a nuestro sistema que consolide la presencia internacional de la empresa por sí mismo).

  • “Adaptar el sistema de información de venta de viajes [a un entorno internacional]” es un objetivo general que apoya el objetivo anterior (y, por lo tanto, es más concreto). En este caso, se podría satisfacer en cuestión de meses pero, de nuevo, no es un requisito de nuestro sistema, sino que todavía habrá que concretar qué requisitos tiene que satisfacer nuestro sistema para que podamos decir que está adaptado a un entorno internacional.

  • “Un cliente de un país de fuera de la zona euro tiene que poder comprar un viaje” es un objetivo de usuario: el cliente de fuera de la zona euro es el usuario y el objetivo es comprar el viaje. En este caso, es de esperar que no necesite varios días para poder comprar el viaje (a pesar de que podría ser el caso).

  • “Ver el precio total” es un objetivo de tarea. No aporta ningún valor por sí mismo si no es como parte del objetivo “Comprar un viaje”. Lo mismo pasa con “el sistema calcule automáticamente la conversión entre divisas”; es parte del escenario de compra del viaje.

  • “Crearán una tabla en la base de datos con la cotización más reciente de la divisa del país en cuestión” y “actualizarán esta información mediante un proceso automático que se ejecutará cada tres horas” son parte de la solución y, por lo tanto, no forman parte de los requisitos del sistema.

4.3.Identificación de requisitos de abajo a arriba (bottom-up)

Hemos visto cómo podemos partir de los objetivos más generales (por ejemplo, los del plan estratégico) e irlos descomponiendo en subobjetivos para ir descubriendo objetivos de usuario y, por lo tanto, requisitos de nuestro sistema de información.
También podemos, sin embargo, hacer el proceso inverso: una vez hemos identificado un objetivo de nivel más bajo, podemos identificar qué objetivos de más alto nivel y stakeholders pueden estar relacionados.
4.3.1.La técnica de los cinco porqués
La técnica de los cinco porqués es una técnica de análisis de relaciones causa-efecto que nos ayuda a encontrar la causa raíz de un problema o de un hecho. Consiste en, partiendo de un hecho, preguntarse cuál es la causa que lo ha provocado y, una vez identificada la causa, volvérsela a preguntar (hasta 5 veces).
Sabemos que un empleado de la agencia quiere indicar su opinión sobre un hotel. Aplicando la técnica de los cinco porqués nos deberían preguntar ¿por qué?

  • Porque quiere que el cliente pueda consultar su opinión, ¿por qué?

  • Porque el cliente quiere recibir asesoramiento a la hora de decidir a qué hotel ir, ¿por qué? Porque el cliente quiere comprar un viaje, ¿por qué?

  • Porque el cliente se va de vacaciones y no quiere organizarse él el viaje, ¿por qué?

  • Porque el cliente no está familiarizado con el destino.

En este caso, hemos identificado una serie de objetivos (cada uno de ellos más general que el anterior) y el proceso nos ha llevado a hacernos preguntas que no nos habíamos planteado hasta ahora, como cuál es el tipo de cliente que esperamos tener (por ejemplo, si viaja por turismo o por negocios) y cuál es el motivo que hace que este cliente nos contrate el viaje en lugar de organizárselo por su cuenta.

4.4.Relación de los stakeholders y los objetivos

Supongamos por un momento que, pasado un tiempo, estamos desarrollando la conversión automática de divisas y nos encontramos que, por el motivo que sea, calcular automáticamente la conversión es más costoso delo que pensábamos originalmente y, por lo tanto, necesitamos revisar la decisión de incluir este requisito. ¿Con quién tenemos que hablar?
Es necesario saber, dado un requisito, cuál es el objetivo que se quiere satisfacer, así como quiénes son los stakeholders que tienen este objetivo.

4.5.Modelado de los objetivos

Para documentar el conocimiento que tenemos sobre los stakeholders y sus objetivos, podemos crear modelos formales de los mismos. Por ejemplo, el lenguaje i* o el método KAOS nos ayudan a representar gráficamente cuáles son los stakeholders del sistema, cuáles son sus objetivos y cuál es la relación entre los stakeholders y los objetivos (ya sea una relación positiva o negativa).
KAOS es un método para la ingeniería de requisitos que permite crear modelos de requisitos a partir de modelos de objetivos. Mediante este método, los objetivos se organizan en forma de grafo cíclico tal que:

  • Cada objetivo del modelo (excepto los objetivos estratégicos) está justificado por, como mínimo, otro objetivo que explica por qué se introdujo este objetivo en el modelo.

  • Cada objetivo del modelo (excepto los objetivos de más bajo nivel) se puede refinar como colección de subobjetivos que explican cómo se tiene que obtener el objetivo.

El lenguaje i* es un lenguaje de modelización que nos ayuda a modelizar los agentes que participan en un sistema junto con sus “propiedades intencionales”, como por ejemplo los objetivos, creencias, compromisos, etc.).

5.Caso práctico

En este apartado veremos cómo podemos aplicar algunas de las técnicas que hemos estudiado en el caso de Viajes UOC.

5.1.Clasificación de objetivos

A lo largo del módulo hemos identificado algunos objetivos de los diferentes stakeholders de Viajes UOC. A continuación veremos ejemplos de objetivos en los diferentes niveles basados en la descripción original del sistema.
5.1.1.Objetivos obtenidos de las entrevistas
Consideraremos sólo la entrevista a Joan Salvat (agente de viajes) y María Costa (propietaria de una agencia de viajes).
Joan Salvat tiene un objetivo principal: “Asesorar adecuadamente a los clientes de Internet”. Este objetivo, sin embargo, no es suficientemente concreto como para considerarlo un objetivo de usuario y, de hecho, el propio Joan nos indica cuáles son los subobjetivos que nos pueden ayudar a satisfacer este objetivo: “Ofrecer las recomendaciones a través de Internet” (de forma que los clientes de Internet tengan acceso a sus recomendaciones), “Que el cliente pueda pedir cita con el agente de viajes” (para poder ofrecer asesoramiento personalizado al cliente que ha llegado a través de Internet) y “Que el cliente pueda saber quién ha hecho una recomendación” (para que el cliente pueda determinar con qué agente tiene que pedir la cita en función de su asesoramiento).
El objetivo principal de María Costa es “Conseguir nuevos clientes” pero, al mismo tiempo, “Mantener a los clientes existentes”. Para satisfacer estos objetivos nos propone cosas como “Que los clientes tengan que ir a la agencia aunque sea una vez” o “Que el pago se tenga que hacer en la agencia”.
También nos traslada el objetivo de Martí de “No tener que apoyar” y nos propone “Que exista un mecanismo de solución de incidencias técnicas”.
Finalmente, también nos pide que el nuevo sistema “No requiera formación adicional”.
5.1.2.Objetivos de nivel general/usuario/tarea
Los objetivos más generales que hemos identificado en el subapartado anterior son:

  • Conseguir nuevos clientes

  • Mantener los clientes existentes

Los objetivos más concretos que apoyan el objetivo de conseguir nuevos clientes son:

  • Asesorar adecuadamente a los clientes de Internet.

  • Que los clientes tengan que ir a la agencia aunque sea una vez.

Estos dos objetivos todavía son de nivel general, a pesar de que ya hemos identificado algunos objetivos de usuario que los pueden apoyar:

  • Escribir la recomendación.

  • Que el cliente pueda leer la recomendación.

  • Que el cliente pueda pedir cita con el agente de viajes.

  • Que el cliente pueda saber quién ha hecho una recomendación.

En cuanto al segundo objetivo (mantener los clientes existentes):

  • Que el pago se tenga que hacer en la agencia.

  • Que el cliente pueda pedir cita con el agente de viajes (también nos ayuda con este objetivo).

5.2.Modelo de la interfaz gráfica de usuario

El modelo de la interfaz gráfica de usuario representa la información que se mostrará al usuario y los elementos interactivos que el sistema le ofrecerá para hacer peticiones al sistema (botones, menús, listas desplegables, etc.).
Supongamos que queremos modelar la interfaz gráfica de usuario de los siguientes casos de uso:
Caso de uso: Introducir una recomendación
Actor principal: Agente de viajes
Ámbito: Sistema informático de ventas de Viajes UOC
Nivel de objetivo: Usuario
Stakeholders e intereses:
Agente de viajes: quiere hacer la recomendación
Cliente: querrá leer la recomendación
Precondición: El agente de viajes tiene que haberse identificado al sistema
Garantías mínimas: -
Garantías en caso de éxito: El sistema guardará la recomendación para mostrarla en el futuro.
Escenario principal de éxito:
1) El agente de viajes busca el hotel o el destino sobre el que quiere escribir y, como resultado, el sistema muestra la ficha de detalle del hotel o el destino
2) El agente de viajes escribe su recomendación (que puede ser positiva o negativa)
3) El sistema guarda la recomendación asociada al agente de viajes y el hotel o destino
Extensiones:
1a. El agente de viajes no encuentra el hotel o destino
1a1. El caso de uso finaliza.
3a. El agente de viajes ya había hecho una recomendación sobre aquel hotel o destino
3a1. El sistema avisa al usuario de que se perderá la recomendación anterior
3a2. Si el agente de viajes confirma que la quiere sobrescribir, el sistema guarda la recomendación asociada al agente de viajes y el hotel o destino
Caso de uso: Buscar entidad (donde entidad puede ser cualquier cosa que tenga una ficha de detalle, como, por ejemplo, un destino o un hotel)
Actor principal: Agente de viajes o cliente
Ámbito: Sistema informático de ventas de Viajes UOC
Nivel de objetivo: Tarea
Stakeholders e intereses:
Agente de viajes o cliente: quiere consultar a la ficha de detalle de una entidad
Precondición: -
Garantías mínimas: -
Garantías en caso de éxito: El sistema mostrará la ficha de detalle de la entidad buscada
Escenario principal de éxito:
1) El usuario (sea agente de viajes o cliente) introduce uno o más termas de busca
2) El sistema muestra la lista de entidades que contienen algunos de los términos de busca en alguno de los campos de busca. Para cada entidad muestra los campos a mostrar.
3) El usuario elige una entidad de la lista
4) El sistema muestra la ficha detalle de la entidad
Extensiones:
1a. Busca avanzada (si existe busca avanzada por la entidad)
1a1. El usuario indica que quiere hacer una busca avanzada.
1a2. El sistema le muestra el formulario de busca avanzada donde pide los campos de busca avanzada
1a3. El usuario llena los datos del formulario de busca y volvemos al paso 2 del escenario principal
3a. Refinar la busca
3a1. El usuario introduce nuevos términos de busca
3a2. Volvemos al paso 2 del escenario principal
Caso de uso: Buscar un hotel
Actor principal: Agente de viajes o cliente
Ámbito: Sistema informático de ventas de Viajes UOC
Nivel de objetivo: Tarea
Stakeholders e intereses:
Agente de viajes o cliente: quiere consultar la ficha de detalle de un hotel
Precondición: -
Garantías mínimas: -
Garantías en caso de éxito: El sistema mostrará la ficha de detalle del hotel
Escenario principal de éxito:
1) El usuario busca el hotel usando el caso de uso. Buscar una entidad en la que:

  • La entidad es un hotel

  • Los campos de busca son: nombre del hotel y nombre del destino al que pertenece el hotel

  • Los campos a mostrar son: nombre del hotel y nombre del destino al que pertenece el hotel

  • Sí existe busca avanzada

  • Los campos de busca avanzada son: nombre del hotel, nombre del destino donde se encuentra, precio medio de estancia y mínimo de recomendaciones por parte de los agentes de Viajes UOC

Caso de uso: Buscar un destino
Actor principal: Agente de viajes o cliente
Ámbito: Sistema informático de ventas de Viajes UOC
Nivel de objetivo: Tarea
Stakeholders e intereses:
Agente de viajes o cliente: quiere consultar la ficha de detalle de un destino
Precondición: -
Garantías mínimas: -
Garantías en caso de éxito: El sistema mostrará la ficha de detalle del destino
Escenario principal de éxito:
1) El usuario busca el destino usando el caso de uso. Buscar una entidad en la que:

  • La entidad es un destino

  • Los campos de busca son: nombre del destino

  • Los campos a mostrar son: nombre del destino

  • No existe busca avanzada

Caso de uso: Consultar una recomendación
Actor principal: Cliente
Ámbito: Sistema informático de ventas de Viajes UOC
Nivel de objetivo: Usuario
Stakeholders e intereses:
Agente de viajes: Quiere que el cliente vea la recomendación y que sepa quién lo ha hecho
Cliente: Quiere ver la recomendación
Precondición: -
Garantías mínimas: -
Garantías en caso de éxito: El sistema mostrará la recomendación al cliente
Escenario principal de éxito:
1) El cliente busca el hotel o el destino sobre el cual quiere leer recomendaciones y, como resultado, el sistema muestra la ficha de detalle del hotel o del destino
2) El cliente pide ver todas las recomendaciones sobre aquel hotel o destino
3) El sistema muestra todas las recomendaciones sobre aquel hotel o destino
Extensiones:
2a. El cliente pide ver sólo las recomendaciones positivas
2a1. El sistema muestra sólo las recomendaciones positivas de aquel hotel o destino
2b. El cliente pide ver sólo las recomendaciones negativas
2b1. El sistema muestra sólo las recomendaciones negativas de aquel hotel o destino
3a. El cliente pide ver más recomendaciones por el mismo autor que una de las recomendaciones
3a1. El sistema muestra todas las recomendaciones hechas por aquella persona junto con el nombre del hotel y destino del hotel si se trata de una recomendación sobre un hotel o el nombre del destino si se trata de una recomendación sobre un destino
Las dos búsquedas (de hotel y de destino) funcionan de forma parecida, puesto que usan la misma plantilla. Inicialmente, se introducen unos ciertos términos de busca y se obtiene un listado de resultados:
75593m2011.gif
Una extensión de las búsquedas permite hacer, cuando el caso de uso lo permita, una búsqueda avanzada consistente en buscar por diversos campos de búsqueda:
75593m2012.gif
Cuando el usuario elige una entidad de la lista de resultados de la búsqueda, se muestra una ficha de detalle. Las dos fichas serán diferentes en cuanto a los datos que se muestran en ellas.
Las dos pantallas presentarán, sin embargo, botones que nos permitan encadenar con el paso siguiente de cualquiera de los casos de uso en los que se usarán. En nuestro caso, habrá un botón para ver las recomendaciones y otro para escribir una recomendación.
75593m2013.gif
75593m2014.gif
Para la introducción de recomendaciones, se diseña una pantalla muy sencilla, donde el usuario tiene que hacer explícito si su recomendación es positiva o negativa, además de escribir lo que crea conveniente.
75593m2015.gif
La consulta de recomendaciones tiene que permitir usar las extensiones por las cuales el usuario consulta sólo las recomendaciones positivas o sólo las negativas:
75593m2016.gif
Finalmente, hay una tercera extensión de este caso de uso que permite ver todas las recomendaciones que ha hecho un mismo usuario:
75593m2017.gif

Resumen

En este módulo nos hemos centrado en la obtención de requisitos candidatos, los que se tendrán en cuenta durante la gestión de requisitos para acabar determinando cuáles son los requisitos que se implementarán finalmente.
En cuanto a descubrir requisitos, hemos visto la problemática del IKIWISI, consistente en que muchos stakeholders tienen requisitos que no conocen pero que saben reconocer una vez que los ven. La experimentación nos puede ayudar a solucionar esta problemática mediante prototipos del sistema o modelos de la interfaz gráfica de usuario.
Los prototipos son productos de software que simulan la interfaz de usuario para poder experimentar con los requisitos, pero que una vez utilizados no se aprovechan. Los modelos son esbozos no interactivos de la interfaz de usuario que nos permiten experimentar con los requisitos con un coste mucho más bajo.
Otra fuente para descubrir requisitos ocultos es la innovación en los procesos de negocio de las organizaciones. Así, innovar el servicio, ofrecer más información, fomentar la participación, ofrecer alternativas y considerar el caso de uso completo son algunos ejemplos de innovaciones que nos pueden ayudar a descubrir requisitos que no sabíamos que teníamos.
También hemos estudiado el impacto de las soluciones ya existentes en los requisitos. El uso de productos COTS y de servicios puede ser muy útil para no tener que desarrollar todo el sistema de información desde cero, pero tienen la problemática de tener que buscar el producto o servicio que se adecúe a nuestros requisitos.
Hemos visto que las metodologías de selección de soluciones preexistentes comparten una serie de actividades consistentes en definir un criterio de evaluación, buscar soluciones candidatas que satisfagan los requisitos irrenunciables, evaluar las soluciones candidatas, analizar y seleccionar la solución más adecuada y, finalmente, personalizarla para adaptarla a nuestras necesidades.
Finalmente, hemos visto cómo los objetivos, aquello que quieren los stakeholders, no siempre son requisitos directos del sistema informático que hay que desarrollar. Hay objetivos de nivel general, que suelen afectar no sólo al sistema informático sino también a otros sistemas y personas dentro de la organización, objetivos a nivel de usuario, que son los que un usuario puede lograr sólo usando el sistema informático, y objetivos de nivel de tarea, que son pequeños objetivos que ayudan a lograr los objetivos de nivel de usuario.
Podemos identificar los objetivos de nivel más general al más concreto, pero también podemos hacer un estudio de abajo arriba, en el que estudiamos los objetivos más concretos que tenemos, y nos preguntamos qué objetivos más generales pueden esconder. Finalmente, hemos visto que hay técnicas como i* o KAOS que nos permiten modelar los objetivos de manera formal.

Actividades

1. Suponed que estáis trabajando en la obtención de requisitos de un sistema de información para los usuarios de una red de bibliotecas públicas y que ya habéis encontrado los requisitos más habituales respecto a la consulta del catálogo, el préstamo de libros y su devolución. Nos planteamos descubrir nuevos requisitos candidatos proponiendo ciertas innovaciones en los procesos.
a) Proponed un requisito candidato consistente en introducir una innovación en el servicio.
b) Proponed un requisito candidato consistente en ofrecer más información.
c) Proponed un requisito candidato consistente en fomentar la participación.
d) Proponed un requisito candidato consistente en dar alternativas.
e) Proponed un requisito candidato consistente en considerar el caso de uso completo.
2. Proponed un modelo de la interfaz que permita experimentar con algunos de los requisitos candidatos propuestos en la actividad anterior, para ver si a los stakeholders les interesa realmente y, si es así, averiguar más detalles.
3. Buscad ejemplos del mundo real de servicios como soluciones preexistentes.
a) Dad un ejemplo de PaaS (platform as a service)
b) Dad un ejemplo de IaaS (infrastructure as a service)
c) Dad un ejemplo de SaaS (software as a service)
4. Suponed que queremos seleccionar un componente de base de datos relacional de código abierto para el desarrollo de un sistema de información y que hemos elaborado una plantilla de evaluación de la que, a continuación, se muestra un fragmento:
Capacidades SQL
Todas se puntúan como 0 (sin apoyo), 1 (apoyo parcial) o 2 (apoyo total)
Restricciones de integridad con nombres
Restricciones NOT NULL
Valores por defecto en las columnas
Uso de funciones para indicar los valores por defecto de las columnas
Apoyo de claves foráneas
Actualización de claves foráneas (on delete update)
Evaluad la base de datos MySQL usando el fragmento de plantilla indicado.
5. Pensad en el uso que hacéis del correo electrónico y poned un ejemplo de un objetivo de nivel de organización, de un objetivo de nivel de usuario y de algunos objetivos de nivel de tarea que satisfacéis mediante esta herramienta.

Ejercicios de autoevaluación

1. Indicad dos técnicas de experimentación que nos permitan descubrir requisitos que nadie conoce a priori.

2. Indicad dos inconvenientes del prototipado.

3. Indicad tres criterios que podemos aplicar para descubrir formas de innovación de los procesos, que puedan resultar valiosas para el cliente.

4. Indicad un punto en común y una diferencia entre los componentes de software (COTS) y los servicios.

5. ¿Qué impacto tiene el uso de soluciones preexistentes en la obtención de requisitos?

6. ¿Cuáles son las actividades más típicas a la hora de hacer selección de soluciones preexistentes (COTS y servicios)?

7. A la hora de seleccionar una solución preexistente, ¿todos los requisitos tienen el mismo peso?

8. ¿Todos los objetivos de los stakeholders son requisitos del software?

9. ¿Todos los requisitos del software son objetivos de algún stakeholder?

10. ¿Cuánto se puede tardar en alcanzar un objetivo de nivel de organización?

11. ¿Qué se obtiene de la descomposición de objetivos de nivel de usuario en objetivos de más bajo nivel?

Solucionario

Actividades
1.
a) Se trata de ofrecer un servicio que hasta ahora no se estaba ofreciendo. Supondremos que las tareas que aún se hacen manualmente no se pueden automatizar; el préstamo y la devolución del libro, por ejemplo, hay que hacerlos manualmente, puesto que el libro es un objeto físico que hay que ir a buscar y devolver a la biblioteca. En este sentido, una opción sería ampliar el sistema para contemplar el préstamo de libros electrónicos. De este modo se podrían automatizar también el préstamo y la devolución del libro. Habría que estudiar las implicaciones legales de esto y ver si una biblioteca puede dejar en préstamo un libro electrónico y bajo qué condiciones.
b) Se trata de ofrecer mucha más información de la que se haya considerado hasta ahora. Una opción, en el supuesto que nos ocupa, sería dar más información sobre la disponibilidad de ejemplares de un libro. Podríamos indicar en qué periodos ha estado en préstamo un libro (sin dar información sobre a quién se ha dejado, para respetar su intimidad), y qué préstamos tiene programados en el futuro. Un posible requisito candidato que puede ser interesante sería hacer algún tipo de cálculo del número de ejemplares disponibles, de tal manera que el sistema diera al usuario una estimación de cuántos ejemplares habrá disponibles en una cierta fecha futura. Así, un usuario podría ver, por ejemplo, que un libro del cual no hay ningún ejemplar disponible hoy, está previsto que haya dos disponibles la próxima semana, porque otros usuarios los devuelven.
c) Aquí hay muchos requisitos candidatos posibles. Algunos tienen que ver con formar una comunidad de usuarios del sistema. Así, los usuarios podrían puntuar libros, escribir reseñas u opiniones, sugerir correcciones en los datos del catálogo. En esta línea se puede ir tan lejos como se quiera. Una red social de lectores no es inimaginable.
d) Si suponemos que el sistema que estábamos considerando se tenía que usar por Internet, el uso de dispositivos móviles seguramente ya ha surgido como una necesidad y, por lo tanto, no se puede considerar una alternativa sino un requisito ya identificado. Pero en esta línea podemos pensar en otras opciones. Una posible alternativa podría ser pedir un libro por correo electrónico a través de una red social: el usuario sencillamente tendría que enviar un correo o mensaje indicando qué libro quiere (“busco Tirant lo Blanc de Joanot Martorell”) y el sistema analizaría el correo probando de averiguar qué libro quiere el usuario para reservarlo en préstamo y responder también por correo. Todavía más sencillo sería automatizar así la renovación de préstamos.
e) Si consideramos qué hacía la persona en el momento de usar el sistema, podemos pensar en nuevos requisitos candidatos relacionados con el préstamo de libros, por ejemplo. Cuando una persona pide un libro en préstamo, lo que está haciendo es buscar un libro de su interés, pedirlo en préstamo, usarlo y devolverlo. En cuanto a la búsqueda, podemos imaginar que muchas personas no van a la biblioteca a buscar un libro concreto, sino a buscar algo que les interese. En este sentido, podemos pensar en un posible requisito candidato consistente en recomendar un libro a un usuario. El sistema podría tener en cuenta los gustos del usuario (si, por ejemplo, los usuarios pueden puntuar libros), los préstamos anteriores y pedir al usuario un poco de guía. El sistema podría empezar preguntando al usuario qué busca y ofreciendo respuestas simples, como por ejemplo “una novela”, “un libro de referencia”, “teatro”, “ensayo”, etc. A medida que el usuario fuera escogiendo, se podrían ir acotando las preguntas. Una novela ligera, una novela para hacer reflexionar, una novela para entender la historia...
2. Se propone una pantalla de consulta de los detalles de un libro donde se muestra una posible representación de las puntuaciones de los usuarios, una lista de comentarios de los usuarios y una previsión de disponibilidad de ejemplares.
75593m2018.gif
3.
a) PaaS: Google App Engine es una plataforma de ejecución de aplicaciones de Google.
b) IaaS: Amazon Web Services ofrece varios servicios de infraestructura, como por ejemplo EC2, que ofrece capacidad de cálculo, SimpleDB o RDS que ofrecen bases de datos, o S3 que ofrece espacio de almacenamiento de ficheros.
c) SaaS: Hay muchos ejemplos de software ofrecido como servicio. Un par de los ejemplos más populares en el momento de escribir estos materiales son SalesForce CRM, un CRM ofrecido como servicio, y Google Apps, la suite de Google que ofrece correo electrónico, calendario y herramientas ofimáticas, entre otras aplicaciones, todas ellas como servicios.
4. Se ha evaluado la versión 5.1 de MySQL:
Restricciones de integridad con nombres: 2
Restricciones Not Null: 2
Valores por defecto en las columnas: 2
Uso de funciones para indicar los valores por defecto de las columnas: 0
Apoyo de claves foráneas (Solo en InnoDB): 1
5. La organización, en el caso del correo electrónico, se puede considerar que es la comunidad de usuarios que lo usa. En este caso, podríamos decir que un objetivo de nivel de organización es facilitar la comunicación entre sus miembros.
Un objetivo de nivel de usuario puede ser el envío de un correo electrónico. Este, a su vez, se puede descomponer en objetivos a nivel de tarea, como por ejemplo, seleccionar los destinatarios, escribir el tema o escribir el mensaje.
Ejercicios de autoevaluación
1. El prototipado y el modelado de la interfaz gráfica del usuario. (Véase el apartado 2)
2. El coste de construir un prototipo no es trivial y el prototipo puede dar una falsa sensación de producto final, creando expectativas erróneas al cliente. (Véase el subapartado 2.1.)
3. En los materiales se ven los siguientes: innovar el servicio, ofrecer más información, fomentar la participación, dar alternativas y considerar el caso de uso completo. (Véase el subapartado 2.2.)
4. Ambos términos hacen referencia a soluciones preexistentes, que ofrecen, por lo tanto, una funcionalidad ya implementada. En el caso de los componentes, lo que adquirimos es un componente de software que se usa desde el sistema que estamos implementando, en el mismo ordenador. En el caso de los servicios, en cambio, se trata de sistemas autónomos, que se ejecutan en los ordenadores de la organización que los ofrece y a los que accedemos de forma remota. (Véase el apartado 3.)
5. Por un lado hay que elegir una solución preexistente teniendo en cuenta los requisitos del sistema que se quiere desarrollar, pero por la otra, habrá que contemplar la posibilidad de adaptar el sistema que se quiere desarrollar a aquello que las soluciones ofrecen. (Véase el apartado 3.)
6. Los pasos típicos son:
1) Definir el criterio de evaluación sobre la base de los requisitos del sistema a desarrollar.
2) Buscar los productos y servicios candidatos.
3) Filtrar la lista de candidatos sobre la base de requisitos irrenunciables, aquellos que no son negociables.
4) Evaluar los candidatos restantes según los criterios definidos.
5) Analizar y evaluar los resultados del paso anterior y seleccionar el producto o servicio más adecuado.
6) Personalizar el servicio o producto para reducir las diferencias respecto de los requisitos del sistema a desarrollar.
(Véase el apartado 2.)

7. No. Algunos requisitos se consideran irrenunciables, de tal manera que se usan para filtrar la lista de soluciones candidatas antes de evaluar otros requisitos: aquellas soluciones que no los satisfacen no se consideran. A partir de aquí, cada requisito puede tener un peso diferente a la hora de analizar los resultados de las evaluaciones y de seleccionar la mejor solución. (Véase el apartado 2.)
8. No. Hay objetivos de los stakeholders que no puede satisfacer un sistema informático por sí mismo, puesto que implican a otras personas o entidades dentro de la organización. (Véase el apartado 3.)
9. No directamente. Algunos requisitos pueden ser el resultado de descomponer un objetivo de los stakeholders en partes más pequeñas que el sistema pueda satisfacer. En todo caso, sin embargo, todos los requisitos que no sean objetivos por sí mismo tienen que ayudar a los stakeholders a alcanzar sus objetivos.
10. Lo más habitual es que se tarden días, semanas o incluso años. (Véase el subapartado 3.1.1.)
11. Objetivos de usuario (subobjetivos que tienen un valor intrínseco para el usuario) u objetivos de tarea (subobjetivos que sólo tienen valor dentro del escenario que lleva al usuario a conseguir su objetivo).

Glosario

caso de uso m
Especificación que recoge el contrato entre el sistema y sus stakeholders. Describe el comportamiento del sistema y las interacciones en varios escenarios, mostrando cómo el sistema responde a las peticiones y objetivos de los stakeholders.
COTS m
Del inglés “commercial off the shelf”. Solución de software ya desarrollada y que se encuentra disponible en el mercado en una forma tal que se puede usar directamente.
historia de usuario f
Técnica de documentación de requisitos que hace énfasis en la comunicación verbal y minimiza la documentación escrita. Una historia de usuario está formada por tres componentes: el nombre, la conversación entre los desarrolladores y los clientes y la lista de pruebas que hay que hacer para verificar que se ha implementado correctamente.
IaaS m
Del inglés “infrastructure as a service”. Servicio que ofrece un componente de infraestructura como por ejemplo una base de datos relacional.
IKIWISI m
Del inglés “I’ll know it when I see it”. Término utilizado para hacer referencia al hecho de que un stakeholder no puede describir qué es lo que quiere pero que si lo ve lo reconoce como aquello que quería.
maqueta f
Otro nombre para los modelos de la interfaz gráfica de usuario usados en la modelización.
modelización f
Técnica de experimentación de requisitos consistente en construir modelos de la interfaz gráfica del usuario para experimentar con los requisitos.
objetivo m
Aquello que los stakeholders esperan de nuestro sistema.
objetivo de organización m
Objetivos de nivel muy general que a menudo afectan al conjunto de la organización y que podemos tardar días, semanas o incluso años en alcanzar. En muchos casos, no los puede satisfacer un sistema informático por sí mismo.
objetivo de usuario m
Objetivos con un valor intrínseco para el usuario.
objetivo de tarea m
Dicho de los objetivos que un usuario quiere alcanzar sólo en el contexto de lograr un objetivo de nivel más general, de usuario.
PaaS m
Del inglés “platform as a service”. Servicio que ofrece una plataforma de ejecución de software.
prototipado m
Técnica de experimentación de requisitos consistente en construir un software con aspecto similar al producto final con el mínimo coste posible para poder experimentar con un subconjunto de los requisitos candidatos. Nada delo desarrollado como prototipo se aprovecha para la construcción del producto final.
requisito m
Condición exigida o necesaria para una cosa. En el campo de la ingeniería del software, necesidad o restricción que afecta a un producto de software, definiendo qué soluciones son adecuadas (lo cumplen) y cuáles no (no lo cumplen) desde el punto de vista de esta necesidad o restricción. Una solución será adecuada si satisface todos los requisitos del sistema.
SaaS m
Del inglés “software as a service”. Servicio que ofrece un sistema de software completo, como por ejemplo una hoja de cálculo.
servicio m
Solución de software que se puede contratar de tal forma que la organización contratada ofrece todo lo necesario para utilizarlo, incluyendo la infraestructura hardware, el mantenimiento, etc.
stakeholder m y f
Persona o entidad con un interés sobre el producto que estamos desarrollando.

Bibliografía

Bibliografía principal
Leffingwell, D. (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
Este libro es una buena compilación de técnicas y prácticas relacionadas con los requisitos del software. En concreto, de este módulo nos interesa la parte III, donde nos habla de la visión de producto y de cómo afecta a la gestión de requisitos.
Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley.
Este libro nos da indicaciones sobre cómo hay que aplicar, de manera eficaz, los casos de uso en la gestión de requisitos. A pesar de centrarse en su documentación, su discusión sobre objetivos es aplicable también a la obtención de requisitos, independientemente de que finalmente se documenten mediante casos de uso o no.
Cohn, M. (2004). User Stories Applied. Addison Wesley.
Este libro trata, principalmente, de la técnica de las historias de usuario, pero gran parte del discurso es aplicable a la obtención, gestión y documentación de requisitos con independencia del estilo de documentación.
Davis, A. M. (2005). Just Enough Requirements Management. Dorset House.
En esta obra, Alan Davis propone un enfoque pragmático para la obtención y la gestión de requisitos.
Bibliografía complementaria
Pradel, J.; Raya, J. Ingeniería del software. Editorial UOC.
Los materiales de la asignatura de Ingeniería del software, especialmente el módulo 3, tratan los requisitos de forma introductoria.
Berenbach, B.; Kazmeier, J.; Paulish D. J.; Rudorfer A. (2009). Software & Systems Requirements Engineering in Practice. Mc Graw Hill.
Referencias bibliográficas
Abdallah, M.; Guenther, R.; Armen, E. (2007). “COTS Selection: Past, Present, and FutureProceedings of the 14th Annual IEEE Internation”. Conference and Workshops on theEngineering of Computer-Based Systems (ECBS’07). https://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=4148924&contentType=Conference+Publications&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A4148903%29%26rowsPerPage%3D75/
IEEE-SA Standards Board (1998). IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society.
Sommerville, I. (2005). Integrated Requirements Engineering: A Tutorial. Lancaster University. https://www.computer.org/portal/web/csdl/abs/mags/so/2005/01/s1016abs.htm (Última visita: febrero 2012).
Tomayko, J. E. Engineering of Unstable Requirements Using Agile Methods. Carnegie MellonUniversity. https://cf.agilealliance.org/articles/system/article/file/1162/file.pdf (Última visita: febrero 2012).
Robertson, J. (2002). Eureka! Why Analysts Should Invento Requirements. IEEE Software. https://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1020281&contentType=Journals+%26+Magazines (Última visita: febrero 2012).
Robertson, J.; Robertson, S. Volere Requirements Specification Template. https://www.volere.co.uk/template.htm (Última visita: febrero 2012).
Varios autores (2004-2011). QSOS (Qualification and Selections of Opensource Software). https://www.qsos.org (Última visita, diciembre 2011).