Pid 00230168-2 PDF

Obtención de
requisitos
Jordi Pradel Miquel
Jose Raya Martos
PID_00191266
CC-BY-SA • PID_00191266 Obtención de requisitos
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:
http://creativecommons.org/licenses/by-sa/3.0/es/legalcode.ca
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Técnicas de obtención de requisitos............................................. 7

1.1. Brainstorming .............................................................................. 7
1.2. Modelado de roles de usuario ..................................................... 8
1.3. Entrevistas y cuestionarios .......................................................... 8
1.4. Observación y prototipado ......................................................... 9
1.5. Listas predefinidas ....................................................................... 10
2. Descubrimiento de requisitos......................................................... 12
2.1. Innovación en los procesos ........................................................ 12
3. Soluciones preexistentes................................................................... 15
3.1. Selección de componentes .......................................................... 16
4. Objetivos y requisitos....................................................................... 19
4.1. Relación entre objetivos y requisitos .......................................... 19
4.2. Organización de los objetivos ..................................................... 20
4.2.1. Objetivos generales ........................................................ 22
4.2.2. Objetivos de usuario y de tarea ..................................... 22
4.2.3. Clasificación de objetivos .............................................. 23
4.3. Identificación de requisitos de abajo a arriba (bottom-up) .......... 24
4.3.1. La técnica de los cinco porqués .................................... 25
4.4. Relación de los stakeholders y los objetivos ................................ 25
4.5. Modelado de los objetivos .......................................................... 25
5. Caso práctico....................................................................................... 27
5.1. Clasificación de objetivos ........................................................... 27
5.1.1. Objetivos obtenidos de las entrevistas .......................... 27
5.1.2. Objetivos de nivel general/usuario/tarea ....................... 27
5.2. Modelo de la interfaz gráfica de usuario .................................... 28
Resumen....................................................................................................... 35
Actividades.................................................................................................. 37
Ejercicios de autoevaluación.................................................................. 37
Solucionario................................................................................................ 39
Glosario........................................................................................................ 42
Bibliografía................................................................................................. 43
CC-BY-SA • PID_00191266 5 Obtención de requisitos
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 Ved también
requisitos de un sistema, como el modelado de roles de usuario o las entrevistas
Véase los materiales de Inge-
y cuestionarios, pero aún no hemos entrado en detalle por lo que respecta a niería del software.
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 dife-
rentes stakeholders quieren alcanzar con el nuevo sistema y, por eso, tener co-
rrectamente estructurados e identificados estos objetivos nos ayudará a estruc-
turar 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 sa-
ben que tienen.
3. Saber evaluar el impacto sobre los requisitos de la existencia de una solu-

ció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 con- Ved también

siste en obtener la lista de todos los requisitos que, idealmente, habría de sa-
Véase la asignatura Ingeniería
tisfacer el sistema que se desea desarrollar. del software.
Denominamos requisitos�candidatos a los requisitos obtenidos en esta Terminología
primera etapa, ya que aún no hemos decidido si el sistema que se desea A menudo se usa el término
desarrollar los tiene que cumplir o no. inglés requirements elicitation
para denominar la obtención
de requisitos.
La técnica más básica para la obtención de requisitos es pedirlos a los stakehol-

ders mediante el uso de algunas de las técnicas que comentaremos a continua-
ción.
1.1. Brainstorming
(1)
El brainstorming1 es una técnica de creatividad para grupos que favorece la ge- En español, es habitual el uso del
término lluvia de ideas.
neració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 pre-

sentar 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 res-
ponder 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 brains-
torming.
La idea básica de esta técnica es que, en lugar de buscar los requisitos de to-
dos 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 so-
bre los destinos.”
1.3. Entrevistas y cuestionarios
Esta es una de las técnicas más utilizadas para la obtención de requisitos. Con-
siste, obviamente, en entrevistarse con los stakeholders para obtener directa-
mente de ellos los requisitos que tienen sobre el sistema que hay que desarro-
llar.
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 obte-
ner 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 pro-
totipos.
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).
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), in-

cluso 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 co-

rrespondiente 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.
Esta técnica es especialmente útil para los requisitos no funcionales, ya que, co- Ved también
mo hemos visto anteriormente, estos son independientes del comportamien-
Podéis encontrar más informa-
to del sistema. ción sobre el estándar IEEE-830
en el módulo “Documentación
de requisitos”.
El estándar IEEE-830 incluye una de estas listas. Otra plantilla con una lista
predefinida de requisitos no funcionales es la plantilla Volere.
Referencia bibliográfica
Podéis encontrar la referencia

completa en la plantilla Vo-
lere, en el apartado de biblio-
grafía.
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 simu-
lar 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 re-

quisitos 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 interesan-

tes de probar y poderlas probar con el mínimo coste posible (en tiempo y di-
nero).
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 al-
guien inventara las redes sociales para poder compartir información con los
amigos y familiares”. De hecho, todo el mundo pensaba que tenía esta nece-
sidad 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.
Referencia bibliográfica
“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 D.�Lasdun (1965). “An
Architect’s Approach to Ar-
delante, lo reconoce como aquello que siempre había querido”. (Denys chitecture”. RIBA Journal 72
(núm. 4).
Lasdun, 1965)
A pesar de que esta frase es
original de un arquitecto, es
perfectamente aplicable al
Antes de experimentar con alternativas, necesitamos un criterio para descubrir desarrollo del software.
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 com-
partir 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 mu-
chos 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 acostum- Ejemplo de ofrecer más
bradas a tener mucha información disponible y, con el paso del tiempo, cada información
vez demandamos más información. Un ejemplo típico es el segui-

miento de envíos. No hace
tantos años que era impensa-
En el caso de Viajes UOC, podemos ofrecer más información sobre los destinos (tal y ble poder saber, en todo mo-
como nos han pedido a las entrevistas) pero también tenemos otras oportunidades para mento, en qué punto de la ru-
dar más información a los clientes: por ejemplo, podemos dar información sobre dispo- ta se encontraba un paquete.
nibilidad de plazas en los vuelos y en los hoteles, o sobre el estado de confirmación de En cambio, hoy en día, es una
las reservas de su viaje. información básica que espe-
ramos de cualquier proveedor
de paquetería y que, a veces,
3)�Fomentar�la�participación. Una de las ventajas de dar más información a estamos dispuestos a pagar co-
mo un extra.
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 Ama-
zon. 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 soft-
ware 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, ins-
talaciones, 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 escena-
rio 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 contra-

tación de un servicio, el impacto sobre los requisitos será similar: en los dos
casos habrá que compatibilizar los requisitos del sistema que estamos desarro-
llando 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 so-
lució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 dis-
ponibles 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 se-

lecció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 apli-
QSOS
caciones para teléfonos móviles para desarrollar la versión móvil de Viajes UOC. Lo pri-
mero que deberemos hacer es definir qué criterios de evaluación se aplicarán.
Los ejemplos que se usan en
Supongamos que tenemos un requisito político irrenunciable que la plataforma utilizada estos materiales sobre la se-
lección de una plataforma de
tiene que ser de código abierto. Algunos otros requisitos pueden ser que sea madura, con
desarrollo están inspirados en
un grado de adopción elevado, que esté en desarrollo activo, que esté muy documentada, QSOS (qualification and selec-
que sea portable, que soporte el envío de mensajes SMS, etc. tion of open source software),
un método de selección de
componentes de código abier-
A partir de aquí, hay que buscar una lista de productos o servicios candidatos to.
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 evalua-

ción consistente en puntuar cada requisito según unas categorías. Así, podríamos escri-
bir, 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 impor-
tantes 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 re-
lación entre objetivos y requisitos y que seamos capaces de organizar correc-
tamente 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, orga-
nizaciones 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 expre-
sando un objetivo (comprar un viaje), que dará lugar a uno o más requisitos (poder in-
dicar 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 stakehol-
ders 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 des-
cripció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 Identificación de caso de
el stakeholder y nuestro sistema. Por eso nos puede ser útil pensar en términos uso
de objetivos a la hora de obtener los requisitos candidatos: si identificamos Es una buena práctica recono-
correctamente los objetivos, nos será más fácil descomponerlos en subobjeti- cida el hecho de dar nombre
a los casos de uso a partir del
vos que nos determinen nuevos requisitos. objetivo que el actor princi-
pal quiere lograr. Así, si tene-
mos un caso de uso que nos
En el ejemplo anterior, el objetivo de satisfacer el valor de la marca de Viajes UOC se describe qué tiene que hacer
puede descomponer en objetivos más concretos, como, por ejemplo, “Respetar la imagen un cliente de Viajes UOC para
corporativa de Viajes UOC” (que sí que es una propiedad que el sistema puede satisfacer). comprar un viaje, lo más habi-
tual es usar el objetivo “Com-
prar un viaje” para identificar
Desde el punto de vista opuesto, “Poder crear ofertas exclusivas de una agencia” es un el caso de uso.
requisito candidato que nos aleja del objetivo de “consolidar el valor de la marca” y, por lo
Lo mismo pasa con las histo-
tanto, tener claro el objetivo nos puede ayudar a identificarlo como requisito a descartar.
rias de usuario, donde indica-
mos el objetivo como parte del
nombre de la historia: “Como
Identificar los objetivos, además, nos puede ser útil más adelante, durante la cliente quiero comprar un via-
priorización y selección de requisitos, puesto que nos permitirá saber qué sta- je”.
keholders están relacionados con cada objetivo.
Ved también
4.2. Organización de los objetivos
Veremos la priorización y se-
lección de requisitos en el mó-
Hemos visto que los objetivos se pueden descomponer en subobjetivos, desde dulo “Gestión de requisitos”.
los más generales (como “Consolidar el valor de la marca”) hasta los más con-
cretos (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 des-
cripción.
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, cuan-
do 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 em-

presa” 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: Lectura recomendada
En la bibliografía podéis en-

• Objetivos�generales: expresan por qué tenemos que desarrollar el produc- contrar una descripción de
to. niveles similar en la referen-
cia de Cockburn y en la de
Berenbach, Kasmeier y Pau-
lish.
• Objetivos�de�usuario: expresan qué esperan los usuarios de nuestro siste-
ma.
• Objetivos�de�tarea: expresan qué tareas tienen que llevar a cabo los usua-
rios 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 fun-

cionales, 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 siste-
ma de información.
4.2.2. Objetivos de usuario y de tarea
Los objetivos de usuario, en cambio, están muy relacionados con la funcio-

nalidad 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 co-

mo: “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 “Con-
sultar 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 reco-
mendaciones 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.
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 in-

ternacional]” 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 to-
davía habrá que concretar qué requisitos tiene que satisfacer nuestro siste-
ma 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 ejem-
plo, los del plan estratégico) e irlos descomponiendo en subobjetivos para ir
descubriendo objetivos de usuario y, por lo tanto, requisitos de nuestro siste-
ma de información.
También podemos, sin embargo, hacer el proceso inverso: una vez hemos iden-
tificado 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 cau-

sa-efecto que nos ayuda a encontrar la causa raíz de un problema o de un he-
cho. 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. Apli-
cando 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 mode- Enlace de interés
los de requisitos a partir de modelos de objetivos. Mediante este método, los
Podéis encontrar más in-
objetivos se organizan en forma de grafo cíclico tal que: formación sobre el método
KAOS en la Wikipedia.
• Cada objetivo del modelo (excepto los objetivos estratégicos) está justifi-
cado 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 pue-
de 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 Enlace de interés
agentes que participan en un sistema junto con sus “propiedades intenciona-
Podéis encontrar más
les”, como por ejemplo los objetivos, creencias, compromisos, etc.). información sobre i*
en su sitio web: http://
www.cs.toronto.edu/km/is-
Ejemplo del uso de i* para el modelado de objetivos
tar/.
Fuente: Carlos Cares; Xavier Franch; Anna Perini; Angelo Susi. Towards Interoperability of i* Models using iStarML. Computer Standards & Interfaces (vol. 1, núm. 33, págs. 69-79).
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 ob-
jetivos 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 clien-
tes 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 si-

guientes 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 resul-
tado, 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 reco-
mendació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
Nivel�de�objetivo: Tarea
Agente de viajes o cliente: quiere consultar a la ficha de detalle de una entidad
Precondición: -
Garantías�en�caso�de�éxito: El sistema mostrará la ficha de detalle de la entidad buscada
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
Agente de viajes o cliente: quiere consultar la ficha de detalle de un hotel
Precondición: -
Garantías�en�caso�de�éxito: El sistema mostrará la ficha de detalle del hotel
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
Agente de viajes o cliente: quiere consultar la ficha de detalle de un destino
Precondición: -
Garantías�en�caso�de�éxito: El sistema mostrará la ficha de detalle del destino
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

Nivel�de�objetivo: Usuario
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�en�caso�de�éxito: El sistema mostrará la recomendación al cliente
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 recomen-
daciones
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:
Una extensión de las búsquedas permite hacer, cuando el caso de uso lo per-
mita, una búsqueda avanzada consistente en buscar por diversos campos de
búsqueda:
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 enca-
denar 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.
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.
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:
Finalmente, hay una tercera extensión de este caso de uso que permite ver
todas las recomendaciones que ha hecho un mismo usuario:
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 de-
terminando 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 ayu-
dar 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 infor-
mació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 eva-
luación, buscar soluciones candidatas que satisfagan los requisitos irrenuncia-
bles, 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 stakehol-
ders, 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 siste-
ma informático sino también a otros sistemas y personas dentro de la organi-
zació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 pe-
queñ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 requisi-
tos 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.

MySQL
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 MySQL es un conocido siste-
tarea que satisfacéis mediante esta herramienta. ma gestor de bases de datos re-
lacionales.
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 preexis-
tentes (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.
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 des-
tinatarios, 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, fomen-
tar la participación, dar alternativas y considerar el caso de uso completo. (Véase el subapar-
tado 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 ob-
jetivos 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 co-

municación verbal y minimiza la documentación escrita. Una historia de usuario está forma-
da 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 infra-
estructura 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 mode-

los 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 soft-

ware con aspecto similar al producto final con el mínimo coste posible para poder experi-
mentar con un subconjunto de los requisitos candidatos. Nada delo desarrollado como pro-
totipo 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 com-
pleto, 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 desa-
rrollando.
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 fi-
nalmente 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 independen-
cia 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 Se-

lection: Past, Present, and FutureProceedings of the 14th Annual
IEEE Internation”. Conference and Workshops on theEngineering of
Computer-Based Systems (ECBS’07). http://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 Soft-
ware Requirements Specifications. IEEE Computer Society.
Sommerville, I. (2005). Integrated Requirements Engineering: A Tutorial. Lancaster Univer-

sity. http://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 Mello-

nUniversity. http://cf.agilealliance.org/articles/system/article/file/1162/file.pdf (Última visi-
ta: febrero 2012).
Robertson, J. (2002). Eureka! Why Analysts Should Inven-

to Requirements. IEEE Software. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?
reload=true&arnumber=1020281&contentType=Journals+%26+Magazines (Última visita: fe-
brero 2012).
Robertson, J.; Robertson, S. Volere Requirements Specification Template. http://

www.volere.co.uk/template.htm (Última visita: febrero 2012).
Varios autores (2004-2011). QSOS (Qualification and Selections of Opensource Software).

http://www.qsos.org (Última visita, diciembre 2011).

Pid 00230168-2 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pid 00230168-2 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Obtención de

1. Técnicas de obtención de requisitos............................................. 7

El primer paso para obtener los requisitos de un sistema es identificar lo que

Otro problema que estudiaremos es la relación de nuestro sistema con sistemas

Finalmente, hablaremos sobre el modelado de objetivos. Recordemos que los

El objetivo principal de este módulo es dar a conocer al estudiante un conjunto

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

3. Saber evaluar el impacto sobre los requisitos de la existencia de una solu-

1. Técnicas de obtención de requisitos

Como ya sabemos de asignaturas anteriores, la obtención�de�requisitos con- Ved también

Denominamos requisitos�candidatos a los requisitos obtenidos en esta Terminología

La técnica más básica para la obtención de requisitos es pedirlos a los stakehol-

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 pre-

3) No rechazar ideas inusuales.

4) Combinar y mejorar ideas.

El proceso básico de brainstorming consiste en:

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

“No es experto en informática, aunque tiene experiencia en el uso de Internet y de los

1.3. Entrevistas y cuestionarios

Las claves para que la entrevista sea productiva son:

1) Elegir correctamente a los entrevistados

1.4. Observación y prototipado

El prototipado consiste en construir un software con un aspecto similar al

Lo que distingue un prototipo del producto final es que el prototipo se usa

El prototipado, sin embargo, presenta dos inconvenientes importantes: por

Por todo lo cual, la experimentación se hace, a menudo, con modelos de la

Otra ventaja de las maquetas es que son un elemento de comunicación muy

En algunos entornos ágiles (por ejemplo, empresas “start-up” de Internet), in-

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 co-

La ventaja de este tipo de ciclo de vida es que permite adaptarse rápidamente

1.5. Listas predefinidas

Otra técnica es la de utilizar listas predefinidas de requisitos que nos pueden

Podéis encontrar la referencia

A menudo los stakeholders no están en condiciones de proporcionarnos todos

La experimentación es una herramienta básica para el descubrimiento de re-

También necesitaremos determinar qué alternativas pueden ser más interesan-

2.1. Innovación en los procesos

Si queremos que el nuevo sistema que estamos desarrollando mejore la manera

1)�Innovar�en�el�servicio. Una de las formas básicas de innovación es ofrecer

vez demandamos más información. Un ejemplo típico es el segui-

4)�Ofrecer�alternativas. También puede ser útil pensar en nuevas alternativas

5)�Considerar�el�caso�de�uso�completo. ¿Qué hacía la persona que ha puesto

Cada vez es más habitual la utilización de soluciones preexistentes durante el

El software�COTS es software que ya está desarrollado y se encuentra

También es habitual encontrar este software disponible en forma de servicio

Un servicio es una actividad en la que una parte ofrece a otra, de modo

Un servicio no es un componente de software que adquirimos y ejecutamos

También se podría considerar contratar un servicio de base de datos (relacional o no) a

Ya sea el caso de la compra de un producto de software como el de la contra-

Es por este motivo por lo que las metodologías de evaluación de alternativas

3.1. Selección de componentes

Hay muchas metodologías de selección de COTS, también aplicables a la se-

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

• Buscar productos y servicios candidatos.

• Filtrar la lista de candidatos sobre la base de requisitos irrenunciables

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