1

2.1 Tcnicas para lo obtencin de requerimientos de

software
Introduccin
Un rea importante en la Ingeniera de Software es la Ingeniera de Requerimientos. sta
comprende las actividades:
Obtencin (captura, descubrimiento y adquisicin),
Anlisis (y negociacin),
Especificacin y
Validacin de requisitos.
Adems, establece una actividad de gestin de requerimientos para manejar los cambios,
mantenimiento y trazabilidad de los requerimientos.
El proceso de obtencin de requerimientos, cuya finalidad es comunicar los requerimientos, no
solo es un proceso tcnico, sino tambin un proceso social o de cultura laboral que envuelve a
diferentes personas, lo que conlleva dificultades aadidas a su realizacin por lo que se requieren
de tcnicas para la obtencin de requerimientos

Entrevistas
La entrevista es de gran utilidad para obtener informacin cualitativa tales como opiniones, o
descripciones subjetivas de actividades. Es una tcnica muy utilizada, y requiere una mayor
preparacin y experiencia por parte del entrevistador.
La entrevista se puede definir como un intento sistemtico de recoger informacin de otra
persona a travs de una comunicacin interpersonal que se lleva a cabo por medio de una
conversacin estructurada. Debe quedar claro que no basta con hacer preguntas para obtener
toda la informacin necesaria. Es muy importante la forma en que se plantea la conversacin y la
relacin que se establece en la entrevista, para que no parezca un interrogatorio.
Estos son algunos de los aspectos ms importantes a tener en cuenta al realizar entrevistas:
Preparacin. Es necesario documentarse e investigar la situacin de la organizacin analizando
los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que
estn solamente en la mente del entrevistado y que no son accesibles por otros medios como la
observacin o el anlisis de documentos.
Entrevistar al personal adecuado. La mayora de los analistas adoptan un enfoque top-down,
comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde

Unidad II. Ingeniera de Requerimientos

2
deberan ir las cosas, y terminando por hablar con los empleados que aportan detalles
importantes de la operacin.
Duracin. Una entrevista debera durar un par de horas a lo mximo.
Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y
dar detalles, ms all de simplemente responder si o no.

Desarrollo Conjunto de Aplicaciones (JAD)

Es una tcnica que se utiliza para promover la cooperacin y el trabajo en equipo entre usuarios y
analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto a
analistas de software. La idea es aprovechar la dinmica de grupos aplicando un proceso de
trabajo sistemtico y organizado, apoyado por elementos visuales de comunicacin y comprensin
de soluciones.
Las razones que sirven de base a JAD son las siguientes:
Tiempo. Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino
tambin en redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los
distintos entrevistados.
Dificultad. Es ms difcil apreciar posibles errores en la especificacin de requisitos, ya que slo
el analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar
defectos.
Participacin. El JAD propugna una participacin ms profunda de los usuarios en el proyecto,
hasta tal punto que los usuarios que participan adquieren un cierto sentido de propiedad en el
sistema que se construye.
El JAD no se utiliza demasiado, debido a que requiere una mayor organizacin que las entrevistas y
porque el ambiente o los mtodos de trabajo convencionales en las empresas no facilitan este tipo
de actividades (falta de tiempo, dificultad de coordinacin de tanta gente, dificultad para
convencer a la direccin, etc.). No obstante las empresas que han implantado este mtodo han
informado de importantes ahorros de tiempo en el desarrollo de software, as como de una mayor
satisfaccin de los usuarios con los sistemas construidos.

Desarrollo de Prototipos
Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no
son totalmente operativos) de la aplicacin pedida. Esta tcnica es particularmente til cuando:
El rea de la aplicacin no est bien definida (posiblemente por ser algo muy novedoso).
El costo del rechazo de la aplicacin por los usuarios es muy alto.

Unidad II. Ingeniera de Requerimientos

3
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la
organizacin.
Los prototipos de sistema permiten a los usuarios experimentar para ver cmo ste ayuda a su
trabajo. Fomentan el desarrollo de ideas que desembocan en requerimientos. Adems de permitir
a los usuarios mejorar las especificaciones de requerimientos, el desarrollo de un prototipo tiene
otras ventajas:
1. Al demostrar las funciones del sistema se identifican las discrepancias entre los
desarrolladores y los usuarios.
2. Durante el desarrollo del prototipo, el personal del desarrollo de software puede darse
cuenta de que los requerimientos son inconsistentes y/o estn incompletos.
3. Aunque limitado, se dispone rpidamente de un sistema que funciona y demuestra la
factibilidad y usabilidad de la aplicacin a administrar.
4. El prototipo se utiliza como base para escribir la especificacin para la produccin.
En general, el uso de esta tcnica es un medio que permite solventar objeciones del usuario del
tipo: No s exactamente lo que quiero, pero lo sabr cuando lo vea. Por lo general, la
construccin de prototipos incrementa los costos en las etapas iniciales de un proyecto, pero esto
se recupera en etapas posteriores gracias al mejor entendimiento de los requerimientos por parte
de los desarrolladores. En algunos casos tambin se utiliza como un medio para formalizar la
aceptacin previa del cliente de los requisitos del proyecto.

Observacin
Por medio de esta tcnica el analista obtiene informacin de primera mano sobre la forma en que
se efectan las actividades. Este mtodo permite observar la forma en que se llevan a cabo los
procesos y, por otro, verificar que realmente se sigan todos los pasos especificados. Como
sabemos, en muchos casos los procesos son una cosa en papel y otra muy diferente en la prctica.
Los observadores experimentados saben qu buscar y cmo evaluar la relevancia de lo que
observan.

Estudio de documentacin
Varios tipos de documentacin, como manuales y reportes, pueden proporcionar al analista
informacin valiosa con respecto a las organizaciones y a sus operaciones. La documentacin
difcilmente refleja la forma en que realmente se desarrollan las actividades, o donde se encuentra
el poder de la toma de decisiones. Sin embargo, puede ser de gran importancia para introducir al
analista al dominio de operacin y el vocabulario que utiliza.

Cuestionarios
El uso de cuestionarios permite a los analistas reunir informacin proveniente de un grupo grande
de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos

Unidad II. Ingeniera de Requerimientos

4
ms confiables que otras tcnicas; por otra parte, su amplia distribucin asegura el anonimato de
los encuestados, situacin que puede conducir a respuestas ms honestas.
El inconveniente es que la respuesta puede ser limitada, ya que es posible que no tenga mucha
importancia para los encuestados llenar el cuestionario. Es recomendable conseguir apoyo de la
alta direccin para solicitar a las personas de la organizacin que contesten el cuestionario.
Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe asegurar
que el conocimiento y experiencia de stos sean los indicados para dar respuestas a las preguntas.

Tormenta de ideas (Brainstorming)

Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de
ideas sin juzgar su validez por muy disparatadas que parezcan, y despus de recopilar todas las
ideas se realiza un anlisis detallado de cada propuesta. Esta tcnica se puede utilizar para
identificar un primer conjunto de requisitos en aquellos casos donde no estn muy claras las
necesidades que hay que cubrir, o cuando se est creando un sistema que habilitar un servicio
nuevo para la organizacin.

ETHICS (Implementacin Efectiva de Sistemas Informticos desde

los puntos de vista Humano y Tcnico)
Constituye un mtodo bastante evolucionado para fomentar la participacin de los usuarios en los
proyectos. Creado por E. Mumford en 1979, coordina la perspectiva social de los sistemas con su
implementacin tcnica. Un sistema no tiene xito si no se ajusta a los factores sociales y
organizacionales que rigen a la empresa. Se busca la satisfaccin de los empleados en el trabajo a
travs de estudios integrales. Los requisitos tcnicos del sistema sern los necesarios para mejorar
la situacin de los empleados (y, por lo tanto, su productividad) en funcin de dichos anlisis.

Puntos de Vista
Cualquier sistema de software no trivial debe satisfacer las necesidades de un grupo diverso de
interesados (stakeholders). Cada uno de estos puede tener intereses diferentes en el sistema de
software, y por lo tanto sus necesidades pueden generar requerimientos que tengan conflicto
entre s, o incluso se contradigan.
Los mtodos orientados a puntos de vista (viewpoints) toman en consideracin estas perspectivas
diferentes y las utilizan para estructurar y organizar tanto el proceso de obtencin, como los
requerimientos mismos. Uno de estos mtodos es el mtodo VORD (Definicin de Requerimientos
Orientado a Puntos de Vista), el cual provee un marco de trabajo orientado para la obtencin y
documentacin de requerimientos. Las etapas principales de este mtodo son:
1. Identificacin de puntos de vista, que implica descubrir los que reciben los servicios del
sistema e identificar los servicios especficos que se suministran a cada punto de vista.
Unidad II. Ingeniera de Requerimientos

5
2. Estructuracin de puntos de vista, que comprende agrupar los relacionados en una
jerarqua. Los servicios comunes se ubican en los niveles altos de la jerarqua y se heredan
los puntos de vista de bajo nivel.
3. Documentacin de puntos de vista, que comprende refinar la descripcin de stos y los
servicios identificados.
4. Trazado del punto de vista del sistema, que comprende identificar los objetos en un
diseo orientado a objetos utilizando la informacin del servicio encapsulado en los
puntos de vista.

Escenarios
Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos
especficos. Cada evento de interaccin distinto, o la seleccin de un servicio del sistema, se
documentan como un escenario de eventos distinto. Los escenarios de eventos incluyen una
descripcin del flujo de datos y las acciones del sistema, y documenta las excepciones que puedan
surgir.
Las convenciones para los diagramas utilizados en los escenarios de eventos son:
Los datos proporcionados desde un punto de vista o proporcionados a ste se representan
como elipses.
Las entradas y salidas de la informacin de control se ubican en la parte superior de cada
recuadro.
Las salidas de datos se ubican a la derecha de cada recuadro. Si no estn encerradas,
significa que pertenecen al sistema.
Las excepciones se muestran en la parte inferior del recuadro. Si existen varias
excepciones posibles, stas se encierran en un recuadro.
El nombre del siguiente evento esperado despus de completar el escenario se muestra
en un recuadro sombreado.
Los Casos de Uso son una tcnica que se basa en escenarios para la obtencin de requerimientos.
Actualmente se han convertido en una tcnica fundamental que se utiliza para analizar y describir
modelos de sistemas orientados a objetos. En su forma ms simple, un caso de uso identifica a los
actores involucrados en una interaccin y nombra al tipo de sta.

Etnografa
Los sistemas de software no existen de forma aislada; se utilizan en un contexto social y
organizacional, y los requerimientos de sistemas de software se derivan y se restringen acorde a
ese contexto. Satisfacer esos requerimientos sociales y organizacionales es crtico para el xito del
sistema. Una razn de por qu muchos sistemas de software se entregan pero nunca se utilizan es
porque no se toma en cuenta la importancia de este tipo de requerimientos.

Unidad II. Ingeniera de Requerimientos

6
La etnografa es una tcnica de observacin que se puede utilizar para entender los
requerimientos sociales y organizacionales. Un analista se sumerge por s solo en el entorno
laboral donde el sistema se utilizar. El trabajo diario se observa y se hacen notas de las tareas
reales en las que los participantes estn involucrados. La etnografa es especialmente efectiva para
descubrir dos tipos de requerimientos:
Los requerimientos que se derivan de la forma en la que la gente trabaja realmente ms
que de la forma en la que las definiciones de los procesos establecen que debera trabajar.
Los requerimientos que se derivan de la cooperacin y conocimiento de las actividades de
la gente.
Los estudios etnogrficos pueden revelar los detalles de los procesos crticos que otras tcnicas de
obtencin de requerimientos a menudo olvidan. Sin embargo, puesto que se centran en el usuario
final, este enfoque no es apropiado para descubrir los requerimientos organizacionales o del
dominio. La etnografa tampoco est diseada para identificar nuevas propiedades a agregar al
sistema. Por lo tanto, la etnografa no es un enfoque completo para la obtencin de
requerimientos y debe utilizarse en conjunto con otras tcnicas, como el anlisis de casos de uso.

Estrategia para la obtencin de requerimientos

Hemos descrito un nmero considerable de tcnicas para la obtencin de requerimientos. A
continuacin se sugiere una estrategia de cmo aplicar estas tcnicas dentro de un proceso
ordenado y que aproveche al mximo cada tcnica. Esto evitar que los analistas con poca
experiencia caigan en un error muy comn, que es el de pasar demasiado pronto a las entrevistas,
lo cual es un desperdicio de tiempo.
Los pasos de la estrategia sugerida son:
1. Aprender todo lo que se pueda de los documentos, formularios, informes y archivos
existentes. Es sorprendente lo que se puede aprender de un sistema sin necesidad de
quitarle tiempo a la gente.
2. De ser posible, se observar el sistema en accin. No se plantearn preguntas. Tan slo se
observar y se tomarn notas o dibujos. Conviene asegurarse de que las personas
observadas saben que no se les est evaluando. En caso contrario, harn su trabajo de
manera ms eficaz que lo normal.
3. Disear y distribuir cuestionarios para aclarar aspectos que no se comprenden bien. Ser
tambin buen momento para solicitar opiniones sobre los problemas y las limitaciones.
Los cuestionarios requieren que los usuarios inviertan una parte de su tiempo. Pero son
ellos los que pueden elegir cundo les viene mejor hacerlo.
4. Realizar entrevistas (o sesiones de trabajo en grupo, como JAD). Como ya se ha recogido
una base de requerimientos iniciales en los pasos anteriores, se pueden utilizar las
entrevistas para verificar y aclarar las cuestiones y los problemas de mayor dificultad. En

Unidad II. Ingeniera de Requerimientos

7
este punto se pueden llegar a aplicar algunas de las otras tcnicas cmo Escenarios,
Tormenta de ideas, Puntos de Vista, ETHICS y Desarrollo de Prototipos.
5. Se verifican los requerimientos a travs del uso de tcnicas como Entrevistas, Observacin
y orientados a Puntos de Vista.

Conclusiones
La estrategia anterior no es infalible. Aunque habra que desarrollar una estrategia de
investigacin de hechos para todas las fases pertinentes del desarrollo de sistemas, cada proyecto
tiene sus propias particularidades. A veces, la observacin o los cuestionarios pueden no ser
apropiados. Pero debera mantenerse la idea de recabar siempre todos los hechos que sea posible
antes de concertar entrevistas.

Referencias
Guerra, C. (2007). Obtencin de Requerimientos: Tcnicas y Estrategia. Documento en lnea.
http://sg.com.mx/revista/17/obtencion-requerimientos-tecnicas-y-estrategia#.VWNntFJ5sSV
Consulta: 05, 2015.

Tarea 2
Caso de estudio. Compra-Venta de autos usados en lnea.
Una empresa de compra-venta de autos usados, ha decidido incursionar en Internet, ofreciendo el
servicio de venta de autos. Para ello ha pedido a una empresa desarrolladora de Software, la
ejecucin del proyecto, y ha sugerido que el producto sea entregado en 2 meses.
El cliente ha indicado lo siguiente:
1. Un posible comprador de vehculo podr acceder a la pgina Web del distribuidor para conocer
el precio y comprar un auto del inventario.
2. La aplicacin Web utilizar la informacin del Sistema de Inventario de Vehculos (SIV). Este
sistema mantiene los vehculos y los posibles accesorios de cada uno de ellos. El modelo de datos
que maneja es el siguiente:

Fig. 1 Relacin de tablas

Unidad II. Ingeniera de Requerimientos

8
3. Un comprador potencial, podr buscar un vehculo de dos formas: podr ver todo el inventario,
o filtrar con base a una serie de caractersticas de los vehculos.
4. El formulario debe tener componentes para: Ao de Modelo, Marca del Modelo y Accesorios,
sern llenados a partir de la informacin almacenada en el Sistema de Inventario de Vehculos.
Adicionalmente, un componente de Rango de Precios ofrecer 5 rangos de precio. Cada uno
ser calculado a partir del valor mnimo y mximo del precio de los autos que se tienen en
inventario, y luego, dichos valores sern concatenados para mostrarse de la manera siguiente:
Entre 50,000 y 100,000
Entre 100,001 y 150,000
5. Con base a los parmetros de consulta, ser mostrado un listado con los vehculos disponibles
en el inventario. Si no hay vehculos, el mensaje: No hay vehculos con esas caractersticas, se
desplegar.
6. El comprador podr entonces verificar el listado, y si ve un vehculo que le llame la atencin,
podr seleccionarlo y hacer una consulta detallada, la cual se mostrarn los detalles.
7. Si el posible comprador, decide comprar el vehculo, entonces presionar el botn Comprar,
que lo llevar a un formulario, en donde registrar sus datos, los de su aseguradora y los de su
institucin financiera.
8. Al trmino de esta operacin, presionar el botn: Salvar, lo cual har que el auto
seleccionado quede como comprado en el inventario de vehculos. La informacin de compra se
guardar en la tabla compras, y por ltimo, se enviar un correo de confirmacin al comprador,
informando: el nmero de compra, nombre del comprador, nombre de la aseguradora, nombre de
la financiera, marca del vehculo comprado, modelo, ao-modelo, color, accesorios y precio del
vehculo.
Compra
Nmero de Compra
Nmero de Serie Vehculo
Nombre del Comprador
Direccin del Comprador
Telfono del Comprador
E-mail del Comprador
Nombre de Ca. de Seguros
Agente de Ca. de Seguros
Telfono de Ca. de Seguros
Fax de Ca. de Seguros
Nombre Institucin Financiera
Fax de Institucin Financiera

Unidad II. Ingeniera de Requerimientos

9
Con base en la situacin anterior, se pide que identificar que otras tcnicas utilizaras (decir cules
y con ejemplos de su uso) para la obtencin de los requerimientos siguiendo la estrategia
planteada en la lectura.
Ejemplo: Revisin de documentos, Observacin, Cuestionarios, Entrevistas, Tormenta de ideas y
Escenarios. (Mnimo cuatro tcnicas).
Trabajo en equipo: elabora un documento Word, con introduccin, problema, estrategia y
conclusiones. Mnimo dos cuartillas sin portada, con tipo de letra Arial 11, y 1.5 interlineado.

Unidad II. Ingeniera de Requerimientos