2.

2 TCNICAS DE LA INGENIERA DE REQUISITOS

El proceso de Ingeniera de Requerimientos describe de manera detallada

y precisa cada uno de los aspectos del ciclo de vida de un conjunto de
requerimientos. Este proceso presenta dos grandes ramas: Desarrollo de
requerimientos. Administracin de requerimientos.
Que tiene como propsito producir y analizarlos requerimientos de cliente,
de producto y de componente de producto, incluye las siguientes
actividades: Recoleccin, Anlisis, Especificacin y Verificacin. Recoleccin:
Es el Proceso a travs del cual los clientes (compradores y/o usuarios) y el
desarrollador (contratista) de un sistema de software; descubren, revisan,
articulan, y entienden las necesidades de los usuarios del sistema y las
restricciones que se dan sobre el software y el desarrollo del mismo.
Algunas de las tcnicas y herramientas ms importantes para llevar a cabo
la recoleccin de requerimientos son: Entrevistas: mtodo para descubrir
hechos y opiniones que tienen los posibles usuarios y otros participantes
dentro del sistema que se est desarrollando. A su vez se clasifican en:

Entrevistas cerradas: las preguntas ya estn previstas, tienen un orden y

una forma de ser planteadas que no pueden ser modificadas por el
entrevistador. Es en realidad un cuestionario.
Entrevistas abiertas: en las cuales no se preparan preguntas concretas, y,
por el contrario, se discute con el entrevistado las expectativas que este
tiene del sistema.
Casos de Uso y/o Escenarios: Los casos de uso describen interacciones entre
los usuarios y el sistema, enfatizando en lo que el usuario necesita del
sistema. Los escenarios son ejemplos de sesiones de interaccin entre el
sistema y el usuario, donde un solo tipo de interaccin entre los dos
participantes es simulada y descrita.
Observacin y anlisis social: La observacin permite a los investigadores
observar lo que los usuarios hacen actualmente en un determinado
contexto. Esto permite superar problemas con los participantes del proyecto
que realizan descripciones idealizadas o demasiado simplificadas de los
procesos que se llevan a cabo en sus trabajos.
Lluvia de Ideas: Son sesiones donde todos los participantes brindan sus
ideas para obtener una solucin a una problemtica. Una lluvia de ideas
est compuesta de dos fases: la fase de generacin y la fase de evaluacin.
Durante la generacin las ideas son recolectadas y es importante que no
sean criticadas. Durante la evaluacin de las ideas, las propuestas de
solucin deben ser evaluadas desde diferentes perspectivas.

Prototipos: Es programa de computador que implementa algunos de los

requerimientos de un sistema. Este prototipo puede ser usado para
colaborar con la definicin de los requerimientos, o para facilitar la
evaluacin de alternativas de implementacin de un sistema.
Existen dos grandes tipos de prototipos. Los prototipos no funcionales o
desechables (Throw away), que sirven para entender la dificultad y aclarar
los requerimientos; y los prototipos funcionales o evolutivos (Evolutionary)
que permiten construir una aproximacin del sistema de manera que se
pueda proveer cierta funcionalidad del sistema final y usualmente se
convierten en parte del mismo. Anlisis: Es el proceso de analizar las
necesidades de los clientes y los usuarios para llegar a una definicin de
los requerimientos de software.

Dentro de las prcticas principales se encuentra: JAD (Joint Application

Development): Esta prctica se basa en la creacin de espacios que
permitan celebrar sesiones o reuniones en donde los participantes y directos
interesados dentro del desarrollo del proyecto buscan obtener o generar
conocimiento alrededor del desarrollo que se va a llevar a cabo. En estas
sesiones se trabaja bajo un enfoque comn que permite el fcil
entendimiento de los temas expuestos por parte de los invitados a la sesin

Modelos: Esquema terico, generalmente en forma matemtica, de un

sistema o de una realidad compleja, como la evolucin econmica de un
pas, que se elabora para facilitar su comprensin y el estudio de su
comportamiento. Existen dos tipos de modelos. - Modelo conceptual: Es el
utilizado en la especificacin del sistema, representa los conceptos ms
significativos en el dominio del problema. Nos describe la parte esttica
del problema, es una fotografa del mundo real. - Modelo de
Comportamiento: Utilizado en la parte de diseo del sistema, define la parte
dinmica, es decir, cual debe ser el comportamiento en cada situacin y la
forma de proceder.
Los diagramas de secuencia y de estados son parte de este modelo.
Especificacin: Consiste en el desarrollo de un documento que de manera
clara y precisa contenga y especifique cada uno de los requerimientos del
sistema de software. Verificacin: Es el proceso de asegurar que la
especificacin de requerimientos de software sea acorde con los
requerimientos del sistema, conforme a los estndares de documentacin
de la fase de requerimientos, y que a su vez este documento sea una base
slida para la arquitectura y el diseo.

Esta actividad representa un punto de control interno y externo; interno,

porque se debe verificar internamente lo que se est haciendo, y externo,
porque se debe validar con el cliente.

Administracin de requerimientos: Es un proceso que tiene por objetivo

comprender y controlar los requerimientos. Como todo proceso de
administracin, inicia con la planeacin a la par de la identificacin inicial de
requerimientos. Este proceso tiene diferentes formas que dependen del
proceso de desarrollo de software que se est empleando,
independientemente de esto se deben considerar las siguientes etapas:

2.2 INGENIERIA DE REQUISITOS

Requerimiento: Es una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
*Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema
para satisfacer un contrato, estndar, especificacin u otro documento formal
Tipos de requerimientos: requerimientos funcionales y requerimientos no funcionales.
Ingeniera de requisitos: La Ingeniera de Requisitos (IR) cumple un papel primordial en el
proceso de produccin de software, ya que se enfoca un rea fundamental: la definicin de lo
que se desea producir. Su principal tarea consiste en la generacin de especificaciones
correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, las
necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas
relacionados por la mala gestin de los requisitos en el desarrollo de sistemas.

Actividades de la Ingeniera de Requisitos:

EXTRACCIN: Esta fase representa el comienzo de cada ciclo. Extraccin es el
nombre comnmente dado a las actividades involucradas en el descubrimiento de los requisitos
del sistema.

ANLISIS: Sobre la base de la extraccin realizada previamente, comienza esta fase

en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el
momento.

ESPECIFICACIN: En esta fase se documentan los requisitos acordados con el

cliente, en un nivel apropiado de detalle.

VALIDACIN: La validacin es la etapa final de la IR. Su objetivo es, ratificar los

requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado
para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se
debe implementar. Esto implica verificar que los requisitos sean consistentes y que estn
completos.

2.2 TECNICAS DE LA INGENIERIA DE

REQUISITOS
Tcnicas principales
La ingeniera de requisitos puede ser un proceso largo y arduo para el que se requiere de
habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente,
as que es importante identificar a todos los actores involucrados, considerar sus necesidades y
asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear
varias tcnicas para obtener los requisitos del cliente. Histricamente, esto ha incluido tcnicas tales
como las entrevistas, o talleres con grupos para crear listas de requisitos. Tcnicas ms modernas
incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emplear una
combinacin de estos mtodos para establecer los requisitos exactos de las personas implicadas,
para producir un sistema que resuelva las necesidades del negocio.

Entrevistas
Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se
relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores
crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso
ms frecuente del nuevo sistema.

Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas
individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente
definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un
ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas
implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las
implicaciones cruzadas. A menudo es til la seleccin de un secretario dedicado a la documentacin
de la discusin, liberando al analista del negocio para centrarse en el proceso de la definicin de los
requisitos y para dirigir la discusin.

Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En
sistemas muy complejos stos pueden tener centenares de pginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en
cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los
objetivos crticos del funcionamiento interno que luego darn forma a los comportamientos
apreciables por el usuario.
Luego, se establecen formas de medir el progreso en la construccin, para evaluar en cualquier
momento qu tan avanzado se encuentra el proyecto.

Prototipos
Un prototipo es una pequea muestra, de funcionalidad limitada, de cmo sera el producto final una
vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de
llegar al producto terminado.

Casos de uso
Un caso de uso es una tcnica para documentar posibles requisitos, graficando la relacin del
sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja
negra, y slo se representa su interaccin con entidades externas, permite omitir dichos aspectos y
determinar los que realmente corresponden a las entidades externas. El objetivo de esta prctica es
mejorar la comunicacin entre los usuarios y los desarrolladores, mediante la prueba temprana de
prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta
tcnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por
hacer para completar el diseo final.

Los diseadores tienden a reutilizar el cdigo de los prototipos por temor a perder el tiempo al
comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseo y de la interfaz de usuario. Sin
embargo, no proporcionan explcitamente cules son los requisitos.

Los diseadores y los usuarios finales pueden centrarse demasiado en el diseo de la interfaz de
usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los
diagramas, en los casos donde se espera que el software final tenga diseo grfico, se realizan en
una variedad de documentos de diseo grficos y a menudo elimina todo el color del diseo del
software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusin sobre la
apariencia final de la aplicacin.

2.3 MODELOS DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde
la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el
desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el
cliente desea segn la percepcin del desarrollador. Por lo tanto, es esencial que
los clientes puedan comprender este modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base
para la formacin de todos los dems Modelos en el desarrollo de software. En
general, el cualquier cambio en la funcionalidad del sistema es ms fcil de
hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo
de requisitos que desarrollaremos se basa en la metodologa Objectory (Jacobson
et al. 1992), basada principalmente en el modelo de casos de uso.
Actualmente esta metodologa es parte del Proceso Unificado de Rational (RUP).
REQUISITOS: El modelo de casos de uso sirve para expresar el modelo de
requisitos, el cual se desarrolla en cooperacin con otros modelos como se ver
ms adelante.
ANLISIS: La funcionalidad especificada por el modelo de casos de uso se
estructura en el modelo de anlisis, que es estable con respecto a cambios, siendo
un modelo lgico independiente del ambiente de implementacin.
DISEO: La funcionalidad de los casos de uso ya estructurada por el anlisis es
realizada por el modelo de diseo, adaptndose al ambiente de implementacin
real y refinndose an ms.
IMPLEMENTACIN: Los casos de uso son implementados mediante el cdigo
fuente en el modelo de implementacin.
PRUEBAS: Los casos de uso son probados a travs de las pruebas de
componentes y pruebas de integracin.
DOCUMENTACIN: El modelo de casos de uso debe ser documentado a lo
largo de las diversas actividades, dando lugar a distintos documentos como los
manuales de usuario, manuales de administracin, etc.
El propsito del modelo de requisitos es comprender completamente el problema y
sus implicaciones. Todos los modelos no solamente se verifican contra el modelo
de requisitos, sino que tambin se desarrollan directamente de l. El modelo de
requisitos sirve tambin como base para el desarrollo de las instrucciones
operacionales y los manuales ya que todo lo que el sistema deba hacer se
describe aqu desde la perspectiva del usuario. El modelo de

Requisitos no es un proceso mecnico, el analista debe interactuar

constantemente con el cliente para completar la informacin faltante, y as clarificar
ambigedades e inconsistencias.

El analista debe separar entre los requisitos verdaderos y las decisiones

relacionadas con el diseo e implementacin. Se debe indicar cuales aspectos son
obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la
implementacin. Durante el diseo se debe extender el modelo de requisitos con
especificaciones de rendimiento y protocolos de interaccin con sistemas.
El modelo de comportamiento, basado directamente en el modelo de casos de
uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del
usuario. Este modelo utiliza dos conceptos claves: actores para representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso
para representar qu pueden hacer los actores con respecto al sistema El modelo
de presentacin o modelo de interfaces o borde especifica cmo interacta el
sistema con actores externos al ejecutar los casos de uso, en particular, en los
sistemas de informacin ricos en interaccin con el usuario, especifica cmo se
vern visualmente las interfaces grficas y que funcionalidad ofrecer cada una de
ellas. El modelo de informacin o modelo del dominio del problema especifica los
aspectos estructurales del sistema. Este modelo conceptualiza el sistema segn
los objetos que representan las entidades bsicas de la aplicacin. Aunque en
muchas metodologas se permite especificar la funcionalidad completa del sistema
utilizando el modelo del dominio del problema, incluyendo operaciones formales
sobre los objetos correspondientes a un como apoyo al modelo de casos de uso y
no como una entidad totalmente independiente.
El modelo de comportamiento, basado directamente en el modelo de casos de
uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del
usuario. Este modelo utiliza dos conceptos claves: actores para Representar los
distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso
para representar qu pueden hacer los actores con respecto al sistema El modelo
de presentacin o modelo de interfaces o borde especifica cmo interacta el
sistema con actores externos al ejecutar los casos de uso, en particular, en los
sistemas de informacin ricos en interaccin con el
Usuario, especifica cmo se vern visualmente las interfaces grficas y que
funcionalidad ofrecer cada una de ellas.
El modelo de informacin o modelo del dominio del problema especifica los
aspectos estructurales del sistema. Este modelo conceptualiza el sistema segn
los objetos que representan las entidades bsicas de la aplicacin. Aunque en
muchas metodologas se permite especificar la funcionalidad completa del sistema
utilizando el modelo del dominio del problema, incluyendo operaciones formales

sobre los objetos correspondientes a un modelo de requisitos expresado sin casos

de uso, el modelo del dominio del problema ser de mucha ms ayuda como
apoyo al modelo de casos de uso y no como una entidad totalmente
independiente.

2.4 HERRAMIENTA CASE PARA LA INGENIERIA DE

REQUISITOS
A medida que pasa el tiempo se logra entender que el empleo del software es una
buena opcin para agilizar y sistematizar las tareas en el desarrollo de procesos.
El desarrollo de software no es la excepcin; en este caso dichas herramientas se
han denominado CASE (Ingeniera De Software Asistida Por Computador). Estas
incluyen un conjunto de programas que facilitan la optimizacin de un producto
Ofreciendo apoyo permanente a los analistas, ingenieros de software y
desarrolladores.
CASE es la aplicacin de mtodos y tcnicas que dan utilidades a los programas,
por medio de otros, procedimientos y su respectiva documentacin. En esta
investigacin se hace referencia a las herramientas que ayudan a la gestin de
requisitos; es decir al proceso de identificacin, asignacin y seguimiento de los
mismos, incluyendo interfaz, verificacin, modificacin y control de cada requisito,
durante el ciclo de vida del proyecto. Los cambios/ actualizaciones de requisitos
deben ser gestionados para asegurar que se mantenga la calidad del producto.
Hasta hace poco tiempo las herramientas para la gestin de requisitos de software
se limitaban a editores de texto, los cuales hacan de esta tarea una labor tediosa y
confusa. Actualmente, se cuenta con mltiples opciones, como las que se
mencionan a continuacin:

IRQA 43
Herramienta CASE de Ingeniera de Requisitos, diseada para soportar las
actividades realizadas en el proceso de especificacin de sistemas. sta facilita y
formaliza la comunicacin entre el cliente, el proveedor y los distintos miembros del
equipo de desarrollo. Facilita la captura, organizacin y anlisis de las condiciones,
as como la especificacin de la solucin mediante el apoyo metodolgico
adaptable a cada cliente.

RETO
Esta herramienta propone un modelo de requisitos para capturar los aspectos
funcionales del sistema; bsicamente, mediante tres tcnicas complementarias
entre s: la definicin de la Misin del Sistema, la construccin del rbol de
Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso. Adems,
se introduce un Proceso de Anlisis que permite traducir el Modelo de Requisitos
en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando
una representacin de la informacin
En el segundo prototipo.

CONTROLA
Herramienta de apoyo al proceso de ingeniera de software en pequeas
empresas. Se cre gracias a la expansin que tuvo el mercado y a la generacin
de grandes y pequeas empresas, las cuales requieren Un instrumento para el
desarrollo de sus proyectos. Ofrece recursos importantes tales como:
Administracin de requisitos, administracin de casos de uso, administracin de
casos de prueba y error, planeamiento de liberaciones, administracin de
implementaciones, control de dependencia entre Implementaciones, matriz de
rastreabilidad y rastreabilidad de los requisitos.

OSRMT (Open Source Requirements Management Tool)4

Herramienta libre para la gestin de requisitos, cuyas principales caractersticas
son: trabaja en arquitectura
Cliente/servidor, desarrollada bajo Java; la versin 1.3 trae un mdulo para
manejar la trazabilidad y lo introduce para el control de cambios; as mismo,
genera la documentacin de los requisitos tratados.

JEREMIA5
Se trata exclusivamente de una aplicacin cliente exclusivamente, lo cual no
permite la posibilidad de trabajar en equipo. sta, ayuda durante el desarrollo del
sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo
del ciclo de vida. Con JEREMIA es posible captar las necesidades, analizarlas y
clasificarlas. Implementa un mdulo orientado a la generacin de la documentacin
posible de exportar en formato DocBook XML, la cual junto con los requisitos, se
almacena en una base de datos en MySQL.

RAMBUTAN6

Esta herramienta est basada en XML, realmente consta de un conjunto de

aplicaciones para el usuario final, ayudando a los analistas de sistemas en la
recopilacin y categorizacin de hechos en un documento de especificacin de
requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza
para recopilar los hechos en el lugar donde est ubicado el cliente mientras que la
aplicacin de escritorio recibe la informacin, edita y perfecciona. Ambas
aplicaciones permiten al usuario introducir, modificar y visualizar los datos que
componen un documento de especificacin de requisitos.
Comparada con otras herramientas de gestin de requisitos, Rambutan ofrece las
siguientes ventajas competitivas: Aplicacin cliente para palm (PDAclass),
portabilidad entre plataformas, es independiente de cualquier metodologa de
especificacin de requisitos, y permite distribucin libre.
Existen otras herramientas en estudios para la gestin de requisitos. A
continuacin se mencionan, algunas de las incluidas en el estudio comparativo
presentado por El Consejo Internacional sobre la Ingeniera de Sistemas
(INCOSE)7: CaliberRM, REM, SMART TRACE, SoftREQ, Analyst Real Team
System (ARTS), CARE 3.2, CORE 5.1, Cradle 5.2, Envision VIP, Gatherspace, IBM
Rational RequisitePro, KollabNet Editor 2005, PACE, RaQuest 3.0, RMTrak, RTM,
SLATE REquire 6.5, SoftREQ, UGS Teamcenter 2005, truereq product desktop,
XTie-RT, Specification AnalysisTool (SAT), ECM, Banyan2.2, Contour, Projectricity
3.5, FeaturePlan 2.6, analyst pro, ChangeWare 2.0, aligned elements, Dassault
Systemes CSE 4.0, Polarion ALM for Subversion 3.0, Telelogic DOORS, Accept
360.