1.

INTRODUCCIN
A travs de los aos se ha podido constatar que los requerimientos o requisitos son
la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el
punto de partida para actividades como la planeacin, bsicamente en lo que se
refiere a las estimaciones de tiempos y costos, as como la definicin de recursos
necesarios y la elaboracin de cronogramas que ser uno de los principales
mecanismos de control con los que se contar durante la etapa de desarrollo.
Adems la especificacin de requerimientos es la base que permite verificar si se
alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un
reflejo detallado de las necesidades de los clientes o usuarios del sistema y es
contra lo que se va a estar verificando si se estn cumpliendo las metas trazadas. Es
muy frecuente escuchar entre los conocedores del desarrollo de software
(programas de computadoras), que un gran nmero de los proyectos de software
fracasan por no realizar una adecuada definicin, especificacin, y administracin
de los requerimientos. Dentro de esa mala administracin se pueden encontrar
factores como la falta de participacin del usuario, requerimientos incompletos y el
mal manejo del cambio a los requerimientos.
La Ingeniera de Requerimientos (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
requerimientos en el desarrollo de sistemas.

2. OBJETIVOS
Mostrar los conceptos, tcnicas, metodologas de la ingeniera de requerimientos
dentro del desarrollo de software.

3. JUSTIFICACIN

En la actualidad muchos proyectos de desarrollo de software fracasan por qu no se

realiza o se toma importancia al

anlisis correcto sobre la determinacin de

requerimientos que tienen los usuarios para darle solucin su problema.

Es por tal causa que este trabajo aborda el tema de Ingeniera de Requerimientos,
que facilita todo el proceso de abstraccin organizacin, validacin, cambio y
mantenimiento de los requerimientos del cliente, para luego ser trasformado en un
sistema funcional de acuerdo a las necesidades del cliente.

4. INGENIERA DE REQUERIMIENTOS: CONCEPTOS Y

CARACTERSTICAS
La parte ms difcil de construir un sistema es precisamente saber qu construir.
Ninguna otra parte del trabajo conceptual es tan difcil como establecer los
requisitos tcnicos detallados, incluyendo todas las interfaces con gente, mquinas y
otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal.
Ninguna es tan difcil de corregir ms adelante Entonces, la tarea ms importante
que el ingeniero de software hace para el cliente es la extraccin iterativa y el
refinamiento de los requerimientos del producto. [Frederick P. Brooks, 1987].
Los requerimientos para un sistema son las descripciones de los servicios
proporcionados por el sistema y sus restricciones operativas. Estos requerimientos
reflejan las necesidades de los clientes de un sistema que ayude a resolver algn
problema como el control de un dispositivo, hacer un pedido o encontrar
informacin. El proceso de descubrir, analizar, documentar y verificar estos
servicios y restricciones se denomina Ingeniera de Requerimientos.
La Ingeniera de Requerimientos se define, segn Ortas [Ortas 1997], como un
"conjunto de actividades en las cuales, utilizando tcnicas y herramientas, se analiza
un problema y se concluye con la especificacin de una solucin (a veces ms de
una)."
El propsito fundamental del flujo de trabajo de los requisitos es guiar el desarrollo
hacia el sistema correcto.

Hay diferentes puntos de partida para la captura de requisitos. En algunos casos

comenzamos haciendo un modelo del negocio o partimos de uno ya desarrollado.
En otros casos si es un sistema acotado que no da soporte al negocio podemos partir
de un modelo de objetos sencillo como un modelo del dominio.
En otros casos el cliente puede ya haber desarrollado una especificacin completa
de requisitos no basada en objetos, de la cual podemos partir.
La meta de la ingeniera de requerimientos es entregar una especificacin de
requerimientos de software correcta y completa. La ingeniera de requerimientos
apunta a mejorar la forma en que comprendemos y definimos sistemas de software
complejos. Existen varias definiciones de requerimientos, de entre las cuales
podemos citar las siguientes:
Segn Zave:

Rama de la ingeniera del software que trata con el establecimiento de los

objetivos, funciones y restricciones de los sistemas software.

Asimismo, se ocupa de la relacin entre estos factores con el objeto de

establecer especificaciones precisas.

Segn Barry W. Boehm:
Ingeniera de Requerimientos es la disciplina para desarrollar una
especificacin completa, consistente y no ambigua, la cual servir como base
para acuerdos comunes entre todas las partes involucradas y en dnde se
describen las funciones que realizar el sistema.
Segn Loucopoulos:

Trabajo sistemtico de desarrollo de requisitos, a travs de un proceso

iterativo y cooperativo de anlisis del problema, documentando los resultados

en una variedad de formatos y probando la exactitud del conocimiento
adquirido.
Segn Leite:
Es el proceso mediante el cual se intercambian diferentes puntos de vista para
recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una
combinacin de mtodos, herramientas y actores, cuyo producto es un modelo
del cual se genera un documento de requerimientos.
3

4.1 DEFINICIN DE REQUERIMIENTOS

Los Requerimientos fueron definidos por la (IEEE)
(1) Una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
(2) 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.

(3) Una representacin documentada de una condicin o

capacidad

documentada como las descritas en (1) y (2).

Los requerimientos son una especificacin de lo que debe ser
implementado. Estos son descripciones de cmo el sistema se debe
comportar, de las propiedades y atributos del mismo. Deben ser una
restriccin del proceso de desarrollo del sistema
Los requerimientos especifican qu es lo que el sistema debe hacer (sus
funciones) y sus propiedades esenciales y deseables.

4.2 CLASISFICACIN DE LOS REQUERIMIENTOS

4.2.1 Requerimientos funcionales. Los requerimientos
funcionales son aseveraciones de los servicios que el
sistema debe proveer, como el sistema debe reaccionar a
entradas particulares y como el sistema debe comportarse
bajo situaciones particulares. En algunos casos los
requerimientos funcionales deben describir de manera
explcita, lo que el sistema no debe hacer.

Figura 1. Caso de Uso

Fuente: Tutorial de UML-Casos de uso

4.2.2 Requerimientos no funcionales. Estos requerimientos

son restricciones sobre los servicios y funcionalidades
ofrecidos por el sistema. Estos incluyen restricciones en el
tiempo que se debe demorar un proceso, restricciones
sobre el proceso de desarrollo y estndares. Los
requerimientos no funcionales aplican usualmente sobre el
sistema como un todo. Estos normalmente no aplican a
caractersticas o servicios particulares del sistema.

Figura 2. Tipos de requerimientos no funcionales

Fuente: Ingeniera de Software, I. Somerville, p, 112

4.3 NIVELES

DE

DESCRIPCIN

DE

UN

REQUERIMIENTO
4.3.1 Requerimientos del usuario. Los requerimientos del
usuario para un sistema deben describir los requerimientos
funcionales y no funcionales de tal forma que sean
comprensibles

por

los

usuarios

del

sistema

sin

conocimiento detallado. nicamente deben especificar el

comportamiento externo del sistema y deben evitar, tanto
como sea posible, las caractersticas del diseo del
sistema. Por consiguiente, si se estn redactando
requerimientos del usuario, no se debe utilizar jerga del
software, notaciones estructuradas o formales, o describir
los

requerimientos

por

la

descripcin

de

la

implementacin del sistema. Deben redactarse en un

lenguaje sencillo, con tablas y formularios sencillos
diagramas intuitivos.
4.3.2 Requerimientos del sistema. Los requerimientos del
sistema son versiones extendidas de los requerimientos del
usuario que son utilizados por los ingenieros de software
como punto de partida para el diseo del sistema. Agregan
detalle y explican como el sistema debe proporcionar los
requerimientos del usuario. Pueden ser utilizados como
parte del contrato para la implementacin del sistema y,
por lo tanto deben ser una especificacin completa y
consistente del sistema entero.

4.4 CARACTERSTICAS DE LA DESCRIPCIN DE UN

REQUERIMIENTO
Las caractersticas que tiene una buena descripcin individual de un
requerimiento, que lo diferencian de uno mal descrito, son:
6

 Completo: Cada requerimiento debe describir de manera

completa la funcionalidad que debe cumplir. Debe contener toda
la informacin necesaria para que el desarrollador disee e
implemente tal funcionalidad.
Correcto: Cada requerimiento debe describir de manera precisa
la funcionalidad que se debe construir. Un requerimiento
correcto no debe entrar en conflicto con otro requerimiento.
Slo los usuarios ms representativos del sistema pueden
determinar de manera precisa si un requerimiento es correcto o
no.
Realizable: Debe ser posible implementar cada requerimiento
de acuerdo a las capacidades y limitaciones del sistema y el
medio que lo rodea. Para garantizar que no se determinen
requerimientos no realizables, se recomienda contar con
personal al interior del equipo de analistas de requerimientos
que pueda establecer las limitaciones tcnicas y de costos.
Necesario: Cada requerimiento debe documentar algo que los
clientes realmente necesiten, algo que sea para conformidad de
un sistema externo con el que se tenga interaccin, o para
satisfacer un estndar. Para determinar si un requerimiento es
necesario se debe determinar quin lo propuso, es decir, conocer
su origen.
Priorizable: Es importante asignar una prioridad para cada
requerimiento que indique que tan esencial es el mismo para la
realizacin del producto. Se pueden perder elementos de juicio
para el desarrollo del sistema si se asigna el mismo grado de
prioridad a todos los requerimientos.
No Ambiguo: Todos los lectores de un requerimiento deben
llegar a una misma y consistente interpretacin del mismo. El
lenguaje usado en su definicin, no debe causar confusiones al
lector.
7

 Verificable: Un requerimiento es verificable cuando puede ser

cuantificado de manera que permita hacer uso de los siguientes
mtodos de verificacin: inspeccin, anlisis, demostracin o
Pruebas.

4.5 DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS

En la etapa de especificacin de requerimientos se pueden presentar muchos
inconvenientes los cuales son importantes de prevenir e identificar, a continuacin
se enumeran algunos de estos problemas:

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

La cantidad de requerimientos en un proyecto puede ser difcil de manejar.
Los requerimientos no son obvios y vienen de muchas fuentes.
Se genera ambigedad al expresarlos en palabras.
El usuario no puede explicar lo que hace.
Tiende a recordar lo excepcional y olvidar lo rutinario.
Hablan de lo que no funciona.
El vocabulario utilizado por los usuarios es distinto al de los desarrolladores.
Usan el mismo trmino con distinto significado.
Los requerimientos estn relacionados unos con otros, y a su vez se

relacionan con otras partes del proceso.

Cada requerimiento tiene propiedades nicas y abarcan reas funcionales

especficas.

5. PROCESOS DE LA INGENIERIA DE REQUERIMIENTOS

Importancia de la Ingeniera de Requerimientos
Los principales beneficios que se obtienen de la ingeniera de requerimientos son:
Permite gestionar las necesidades del proyecto en forma estructurada:
Cada actividad de la IR consiste de una serie de pasos organizados y

bien definidos.
Mejora la capacidad de predecir cronogramas de proyectos, as como
sus resultados: La IR proporciona un punto de partida para controles
subsecuentes y actividades de mantenimiento, tales como estimacin
de costos, tiempo y recursos necesarios.

Disminuye los costos y retrasos del proyecto: muchos estudios han

demostrado que reparar errores por un mal desarrollo no descubierto

a tiempo, es sumamente caro.

Mejora la calidad del software: La calidad en el software tiene que
ver con cumplir un conjunto de requerimientos (funcionalidad,

facilidad de uso, confiabilidad, desempeo, etc.

Mejora la comunicacin entre equipos: La especificacin de
requisitos representa una forma de consenso entre clientes y
desarrolladores, si este consenso no ocurre, el proyecto no ser

exitoso.
Evita rechazos de usuarios finales: La ingeniera de requerimientos
obliga al cliente a considerar sus requerimientos cuidadosamente y
revisarlos dentro del marco del problema, por lo que se involucra
durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniera de Requerimientos

Son muchas las personas involucradas en el desarrollo de los requerimientos de un
sistema. Es importante saber que cada una de esas personas tienen diversos intereses
y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento
de cada papel desempeado, asegura que se involucren a las personas correctas en
las diferentes fases del ciclo de vida, y en la diferentes actividades de la IR.
No conocer estos inters puede ocasionar una comunicacin poco efectiva entre
clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo
como presupuesto. Los papeles o roles ms importantes pueden clasificarse en :

Usuario Final: Son las personas que utilizaran el sistema

desarrollado. Ellos estn relacionados con la disponibilidad y la
fiabilidad del sistema; estn familiarizados con los procesos
especficos que debe realizar el software, dentro de los parmetros de
su ambiente laboral. Sern quienes utilicen las interfaces y los

manuales de usuario.
Usuario Lder: Son los individuos que comprenden el ambiente del
sistema o el dominio del problema en donde ser implementado el

software desarrollado. Ellos proporcionan al equipo tcnico los

detalles y requerimientos de las interfaces del sistema.

Personal de Mantenimiento: Para proyectos que requieran un
mantenimiento eventual, estas personas son las responsables de la
administracin de cambios, de la implementacin y resolucin de
anomalas, Su trabajo consiste en revisas y mejorar los procesos del

producto ya finalizado.
Analistas y Programadores: Son los responsables del desarrollo del

producto en s, ellos interactan directamente con el cliente.

Personal de Pruebas: Se encargan de elaborar y ejecutar el plan de
pruebas para asegurar que las condiciones presentadas por el sistema
son las adecuadas. Son quienes van a validar si los requerimientos
satisfacen las necesidades del cliente.

OTRAS PERSONAS INVOLUCRADAS

Dependiendo de la magnitud del proyecto, pueden ser:

Administradores de proyecto: Responsable de administrar los

procesos internos del desarrollo de sistemas, para este cargo es
necesario contar con habilidades de administracin para evadir las
diferentes situaciones que se presenten y adems garantizar el
cumplimiento de los objetivos dentro de los tiempos estipulados.
Estas habilidades van desde la definicin del proyecto, hasta la

administracin de las medidas de avance del mismo.

Documentores: Es el encargado de evidenciar la informacin
generada a lo largo del desarrollo del producto hasta lanzamiento,
algunos

de

los

informes

que

se

debe

realizar

son

la

prototipacion( especificaciones, etc.), recopilacin de informacin

(anlisis), validacin de manual (pruebas de uso) y distribucin (por
ejemplo. documentacin impresa en papel). Cada etapa del proceso
afecta a todas las dems etapas y debiera ser creada en conjunto con
todas las otras etapas de desarrollo.
10

Diseadores de base de datos: Es el encargado de desglosar el

problema en diferentes subsistemas, identificar la concurrencia
inherente al problema, asignar los subsistemas a los procesadores y
tareas, seleccionar los almacenes de datos, manejar el acceso a
recursos globales, implementando el control del software.

6. ACTIVIDADES DE LA INGENIERA DE REQUERIMIENTOS

En el proceso de IR son esenciales diversas actividades. En un proceso de Ingeniera
de Requerimientos efectivo, estas actividades son aplicadas de manera continua y en
un orden variado.
Dependiendo del tamao del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto de numero
como de nombres, la figura 3 muestra algunos ejemplos de las actividades
identificadas para cada proceso.

Figura 3. Actividades de la IR para diferentes modelos de proceso

Fuente: Monografa Ingeniera de Requerimientos, Ma. de Lourdes Peres Huebe 2005.

11

La ingeniera de requerimientos es un proceso que comprende todas las actividades

para crear y mantener los requerimientos de un sistema.
Comprende cuatro subprocesos de alto nivel:
1.
2.
3.
4.

Estudio de viabilidad
Obtencin y anlisis de requerimientos
Especificacin de requerimientos
Validacin de requerimientos

Figura 4. El proceso de ingeniera de requerimientos

Fuente: Ingeniera de Software 7ma. Ed., I. Somerville, p, 130

Las actividades que se muestran en la Figura anterior se refieren al descubrimiento,

documentacin y verificacin de requerimientos. Sin embargo, en casi todos los
sistemas los requerimientos cambian. Las personas involucradas desarrollan una
mejor comprensin de lo que quieren que haga el software; la organizacin que
compra el sistema cambia; se hacen modificaciones a los sistemas hardware,
software y al entorno organizacional. El proceso de gestionar estos cambios en los
requerimientos se denomina gestin de requerimientos.

6.1.

ESTUDIOS DE VIABILIDAD

Es un conjunto de requerimientos de negocio preliminares, una descripcin

resumida del sistema y de cmo ste pretende contribuir a los procesos del negocio.
12

Los resultados del estudio de viabilidad deberan ser un informe que recomiende si
merece o no la pena seguir con la ingeniera de requerimientos y el proceso de
desarrollo del sistema.
Un estudio de viabilidad es un estudio corto y orientado a resolver varias preguntas:

el sistema contribuye a los objetivos generales de la organizacin?

el sistema se puede implementar utilizando la tecnologa actual y con las

restricciones de costo y tiempo?

el sistema puede integrarse a otros que existe en la organizacin?

Un estudio de viabilidad comprende la evaluacin y recopilacin de la informacin,

y la redaccin de informes.
La fase de evaluacin de la informacin identifica la informacin necesaria para
poder responder las 3 preguntas anteriores. Una vez que se identific la informacin
se debe hablar con las fuentes de informacin para descubrir las respuestas a estas
posibles preguntas:
1. Cmo se las arreglara la organizacin si no se implementara este
sistema?
2. Cules son los problemas con los procesos actuales y cmo ayudara un
sistema nuevo a aliviarlos?
3. Cul es la contribucin directa que har el sistema a los objetivos y
requerimientos del negocio?
4. La informacin se puede obtener y transferir a otros sistemas de la
organizacin?
5. Requiere el sistema tecnologa que no se ha utilizado previamente en la
organizacin?
6. A qu debe ayudar el sistema y a qu no necesita ayudar?

13

Se pueden consultar las fuentes de informacin, como los jefes de los departamentos
donde se utilizar el sistema, los ingenieros de software que estn familiarizados
con el tipo de sistema propuesto, los expertos en tecnologa y los usuarios finales
del sistema. Normalmente, se debera intentar completar un estudio de viabilidad en
dos o tres semanas.
Una vez que se tiene la informacin, se redacta el informe del estudio de viabilidad.
Debera hacerse una recomendacin sobre si debe continuar o no el desarrollo del
sistema. En el informe, se pueden proponer cambios en el alcance, el presupuesto y
la confeccin de agendas del sistema y sugerir requerimientos adicionales de alto
nivel para ste.

6.2.

OBTENCIN Y ANALISIS DE REQUERIMIENTOS

Es esta etapa del proceso de ingeniera de requerimientos. En esta actividad los

ingenieros de software trabajan con los clientes y usuarios finales del sistema para
determinar el dominio de la aplicacin, que servicios debe proporcionar el sistema,
rendimiento requerido del sistema las restricciones hardware, etc.
Obtencin (Elicitacin)
El primer paso consiste en conocer y comprender las necesidades y problemas del
cliente. En la obtencin se identifican todas las fuentes de requisitos implicadas en
el sistema y, en funcin de las caractersticas del entorno y del proyecto se emplean
las tcnicas ms apropiadas para la identificacin de las necesidades que deben
satisfacerse y transmitir o comunicar esas necesidades.
La Elicitacin de Requisitos ER es la piedra angular en el desarrollo de
proyectos software y tiene un impacto muy alto en el diseo y en las dems fases
del ciclo de vida del producto. Si se realiza apropiadamente, puede ayudar a reducir
los cambios y

las correcciones en los requisitos. Adems, la calidad de la

Elicitacin determina la exactitud de la retroalimentacin al cliente acerca de la

integridad y validez de los requisitos. Debido a que esta fase es crtica y de alto
impacto en el proyecto, es muy importante que la labor de elicitar se realice lo ms
cercano posible a la perfeccin. Teniendo en cuenta las diferentes caractersticas
14

de los proyectos software, en este trabajo se proponen algunas reglas generales para
llevar a cabo la RE con base en la discusin y en la explicacin de los procesos
relacionados y mtodos aplicados en los diferentes tipos de proyectos software.

Anlisis
Una vez obtenida la informacin necesaria del entorno, es necesario sintetizarla,
darle prioridades, analizar posibles contradicciones o conflictos, descomponer el
sistema y distribuir las necesidades de cada parte, delimitar los lmites del sistema y
definir su interaccin con el entorno.
La obtencin y anlisis de requerimientos pueden afectar a varias personas de la
organizacin.
El trmino stakeholder se utiliza para referirse a cualquier persona o grupo que se
ver afectado por el sistema, directa o indirectamente. Entre los stakeholders se
encuentran los usuarios finales que interactan con el sistema y todos aquellos en la
organizacin que se pueden ver afectados por su instalacin.
Obtener y comprender los requerimientos de los stakeholders es difcil por varias
razones:
1. Los stakeholders a menudo no conocen lo que desean obtener del sistema
informtico excepto en trminos muy generales; puede resultarles difcil
expresar lo que quieren que haga el sistema o pueden hacer demandas
irreales debido a que no conocen el coste de sus peticiones.
2. Los stakeholders expresan los requerimientos con sus propios trminos de
forma natural y con un conocimiento implcito de su propio trabajo. Los
ingenieros de requerimientos, sin experiencia en el dominio del cliente,
deben comprender estos requerimientos.
3. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar
de varias formas. Los ingenieros de requerimientos tienen que considerar
todas las fuentes potenciales de requerimientos y descubrir las concordancias
y los conflictos.
4. Los factores polticos pueden influir en los requerimientos del sistema. Por
ejemplo, los directivos pueden solicitar requerimientos especficos del
sistema que incrementarn su influencia en la organizacin.
15

5. El entorno econmico y de negocios en el que se lleva a cabo el anlisis es

dinmico. Inevitablemente, cambia durante el proceso de anlisis. Por lo
tanto, la importancia de ciertos requerimientos puede cambiar. Pueden
emerger nuevos requerimientos de nuevos stakeholders que no haban sido
consultados previamente.
Las actividades del proceso son:
1. Descubrimiento de requerimientos. Es el proceso de interactuar con los
stakeholders

del

sistema

para

recopilar

sus

requerimientos.

Los

requerimientos del dominio de los stakeholders y la documentacin tambin

se descubren durante esta actividad.
2. Clasificacin y organizacin de requerimientos. Esta actividad toma la
recopilacin no estructurada de requerimientos, grupos relacionados de
requerimientos y los organiza en grupos coherentes.
3. Ordenacin por prioridades y negociacin

de

requerimientos.

Inevitablemente, cuando existen muchos stakeholders involucrados, los

requerimientos entrarn en conflicto. Esta actividad se refiere a ordenar
segn las prioridades los requerimientos, y a encontrar y resolver los
requerimientos en conflicto a travs de la negociacin.
4. Documentacin de requerimientos. Se documentan los requerimientos y se
entra en la siguiente vuelta de la espiral. Se pueden producir documentos de
requerimientos formales o informales.
La figura que se muestra a continuacin muestra un modelo muy general del
proceso de obtencin y anlisis de requerimientos.

16

Figura 5. Proceso de obtencin y anlisis de requerimientos

Fuente: Ingeniera de Software 7ma. Ed., I. Somerville, p, 134

Cada organizacin su propia versin o instancia de este modelo en general

dependiendo de los factores locales como la habilidad del personal el tipo de
sistema a desarrollar y los estndares utilizados.

6.3.
El

ESPECIFICACIN DE REQUERIMIENTOS
descubrimiento

de

requerimientos

(llamado

veces

adquisicin

de

requerimientos) es el proceso de recoger informacin sobre el sistema propuesto y

los existentes en la empresa y extraer los requerimientos del usuario y del sistema
de esta informacin.
Las fuentes incluyen la documentacin, los stakeholders del sistema y la
especificacin de sistemas similares.
El encargado de este proceso se relaciona con los stakeholders atreves de la
entrevista y la observacin, puede utilizar escenarios y prototipos para ayudar al
descubrimiento de requerimientos.
Estas fuentes de requerimientos (stakeholders, dominio, sistemas) se pueden
representar como puntos de vista del sistema, donde cada uno representa un

17

subconjunto del sistema y cada punto proporciona una perspectiva nueva del
sistema pero son independientes.

6.4. HERRAMIENTAS DE ADQUISICIN DE

REQUERIMIENTOS
6.4.1. PUNTOS DE VISTA
Los enfoques orientados a puntos de vista para la ingeniera de
requerimientos) Mullery, 1979; Finkelstein et al., 1992 Kotonya y
Sommerville, 1992; Kotonya y Sommerville, 1996) organizan tanto
el proceso de obtencin como los requerimientos mismos utilizando
puntos de vista. Un punto clave del anlisis orientado a puntos de
vista es que reconoce varias perspectivas y proporciona un marco de
trabajo para descubrir conflictos en los requerimientos propuestos por
diferentes estakeholders.
Los puntos de vista se pueden utilizar como una forma de clasificar
los stakeholders y otras fuentes de requerimientos. Existen tres tipos
genricos de puntos de vista:

Puntos de vista de los interactuadores: representan a las

personas u otros sistemas que interactan directamente con el
sistema.

Puntos de vista indirectos: representan a los stakeholders

que no utilizan el sistema ellos mismos pero que influyen en los
requerimientos de algn modo.

Puntos de vista del dominio: representan las caractersticas y

restricciones del dominio que influyen en los requerimientos del
sistema.
Por lo general, estos puntos de vista proporcionan diferentes tipos de
requerimientos. Los puntos de vista de los interactuadores
proporcionan requerimientos detallados del sistema que cubren las
caractersticas e interfaces del mismo. Los puntos de vista indirectos
es ms probable que proporciones requerimientos y restricciones

18

organizacionales de alto nivel. Los puntos de vista del dominio

proporcionan restricciones del dominio que se aplican al sistema.
6.4.2. ENTREVISTAS
Las entrevistas formales o informales con los stakeholders del
sistema son parte de la mayora de los procesos de la ingeniera de
requerimientos. En estas entrevistas, el equipo de la ingeniera de
requerimientos hace preguntas a los stakeholders sobre el sistema que
utilizan y sobre el sistema a desarrollar. Los requerimientos
provienen de las respuesta a estas preguntas. Las entrevistas pueden
ser de dos tipos:

Entrevistas cerradas donde los stakeholders responden a un

conjunto predefinido de preguntas.

Entrevistas abiertas donde no hay un programa predefinido.
El equipo de la ingeniera de requerimientos examina una
serie de cuestiones con los estakeholders del sistema y, por lo
tanto, desarrolla una mejor comprensin de sus necesidades.

Las entrevistas sirven para obtener una comprensin general de lo que hacen
los stakeholders, como podran interactuar con el sistema y las dificultades a
las que se enfrentan con los sistema actuales. A la gente le gusta hablar de su
trabajo y normalmente se alegran de verse implicados en las entrevistas. Sin
embargo, no son de tanta utilidad para la comprensin de los requerimientos
del dominio de la aplicacin.
Es difcil obtener conocimiento del dominio durante las entrevistas debido a
dos razones:
1. Todos los especialistas de la aplicacin utilizan terminologa y jerga
especifica de un dominio. Es imposible para ellos discutir requerimientos
del dominio sin utilizar esta terminologa. Normalmente la utilizan de un
modo preciso y sutil, por lo que es fcil que la malinterpreten los
ingenieros de requerimientos.

19

2. Cierto conocimiento del dominio es tan familiar para los stakeholders

que o lo encuentran difcil de explicar o piensan que es tan bsico que no

merece la pena mencionarlo.
La informacin de la entrevista complementa otras informaciones sobre el
sistema de los documentos. Observaciones de los usuarios, etc. Algunas
veces, aparte de la informacin de los documentos, las entrevistas pueden
ser la nica fuente de informacin sobre los requerimientos del sistema. Sin
embargo, las entrevistas por s mismas tienden a omitir informacin
esencial, por lo que deberan ser usadas al lado de otras tcnicas de
obtencin de requerimientos.
6.4.3. ESCENARIOS
Normalmente, las personas encuentran ms fcil dar ejemplos de la vida
real que descripciones abstractas. Pueden comprender y criticar un
escenario de cmo podra interactuar con un sistema software. Los
ingenieros de requerimientos pueden utilizar la informacin obtenida de
esta discusin para formular los requerimientos reales del sistema.
Los escenarios pueden ser especialmente tiles para agregar detalle a un
esbozo de la descripcin de requerimientos. Son descripciones de
ejemplos de las sesiones de interaccin. Cada escenario abarca uno o ms
posibles interacciones. Se han desarrollado varias formas de escenarios,
cada una de las cuales proporciona diferentes tipos de informacin en
diferentes niveles de detalle sobre el sistema. Utilizar escenarios para
describir requerimientos es una parte fundamental de los mtodos agiles,
como la programacin extrema
El escenario comienza con un esbozo de la interaccin, durante la
obtencin, se agregan detalles para crear una descripcin completa de esta
interaccin. De forma general un escenario puede incluir.
1.

Una descripcin de lo que esperan el sistema y los usuarios cuando el

2.
3.

escenario comienza.
Una descripcin del flujo normal de eventos en el escenario.
Una descripcin de lo que puede ir mal y cmo manejarlo.

20

4.

Informacin de otras actividades que se podran llevar a cabo al

5.

mismo tiempo.
Una descripcin del estado del sistema cuando el escenario termina.
De forma alternativa, se puede adoptar un enfoque ms estructurado,
como los escenarios de eventos o los casos de uso.

6.4.4. CASOS DE USO

Los casos de uso son una tcnica que se basa en escenarios para la
obtencin de requerimientos que se introdujeron por primera vez en el
mtodo Objetor (Jacobsen et al. 1993). Actualmente se han convertido en
una caracterstica fundamental de la notacin de UML, que se utiliza para
escribir modelos de sistemas orientados a objetos. En su forma ms
simple, un caso de uso identifica el tipo de interaccin y los actores
involucrados.
Algunas veces existe confusin sobre si un caso de uso es un escenario o,
como sugiere Fowler (Fowler y Scott, 1997), un caso de uso encierra un
conjunto de escenarios, y cada uno de estos es un hilo nico a travs del
caso de uso. Si un escenario incluye mltiples hilos, habr un escenario
para la interaccin normal y escenarios adicionales para las posibles
excepciones.
Los escenarios y los casos de uso son tcnicas eficaces para obtener
requerimientos para los puntos de vista de los interactuadores, donde cada
tipo de interaccin se puede representar como un caso de uso. Tambin se
pueden utilizar conjuntamente con algunos puntos de vista indirectos
cuando estos reciben resultados. (Como un informe de gestin) del
sistema. Sin embargo debido a que se centran en las interacciones, no son
tan eficaces para obtener restricciones y requerimientos de negocio y no
funcionales de alto nivel de puntos de vista indirectos o para descubrir
requerimientos del dominio.
6.4.5. ETNOGRAFA

21

La etnografa es una tcnica de observacin que se puede utilizar para

entender los requerimientos sociales y organizacionales. Un anlisis se
sumerge por si solo en el entorno laboral donde se utilizara el sistema.
Observa el trabajo diario y anota las tareas reales en las que los
participantes estn involucrados. El valor de la etnografa es que ayuda a
los analistas a descubrir los requerimientos implcitos que reflejan los
procesos reales ms que los formales en los que la gente est involucrada.
La etnografa se puede combinar con la construccin de prototipos
(Figura 6 ). La etnografa suministra informacin al desarrollo del
prototipo de forma que se requieren ciclos de refinamiento. Adems, la
construccin de prototipos se centra en la etnografa para identificar
problemas

y preguntas que se puedan discutir posteriormente en el

etngrafo. Este se debe buscar las respuestas a estas preguntas durante la

siguiente fase de estudio del sistema.

Figura 6. Etnografa y construccin de prototipos para el anlisis de requerimientos

Fuente: Ingeniera de Software 7ma. Ed., I. Somerville, p, 143

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. Los estudios etnogrficos no siempre

pueden identificar nuevas propiedades que se deban agregar al sistema.
Por lo tanto, la etnografa no es un enfoque completo para la obtencin de
requerimientos por s mismo, y debe utilizarse para complementar otros
enfoques, como el anlisis de casos de uso.

22

6.4.6. SISTEMAS EXISTENTES

Esta tcnica consiste en analizar distintos sistemas ya desarrollados que
estn relacionados con el sistema a ser construido. Por un lado, podemos
analizar las interfaces de usuario, observando el tipo de informacin que
se maneja y cmo es manejada, por otro lado tambin es til analizar las
distintas salidas que los sistemas producen (listados, consultas, etc.),
porque siempre pueden surgir nuevas ideas sobre la base de estas.

6.4.7. LLUVIA DE IDEAS

Este es un modelo que se usa para generar ideas. La intencin en su
aplicacin es la de generar la mxima cantidad posible de requerimientos
para el sistema. No hay que detenerse en pensar si la idea es o no del todo
utilizable. La intencin de este ejercicio es generar, en una primera
instancia, muchas ideas. Luego, se irn eliminando en base a distintos
criterios como, por ejemplo, "caro", "impracticable", "imposible", etc.
Las reglas bsicas a seguir son:
Los participantes deben pertenecer a distintas disciplinas

y,

preferentemente, deben tener mucha experiencia. Esto trae aparejado la

obtencin de una cantidad mayor de ideas creativas.
Conviene suspender el juicio crtico y se debe permitir la evolucin de
cada una de las ideas, porque si no se crea un ambiente hostil que no
alienta la generacin de ideas.
Por ms locas o salvajes que parezcan algunas ideas, no se las debe
descartar, porque luego de maduradas probablemente se tornen en un
requerimiento sumamente til.
A veces ocurre que una idea resulta en otra idea, y otras veces podemos
relacionar varias ideas para generar una nueva. Escribir las ideas sin
censura
6.4.8. PROTOTIPOS
Durante la actividad de extraccin de requerimientos, puede ocurrir que
algunos requerimientos no estn demasiado claros o que no se est muy
23

seguro de haber entendido correctamente los requerimientos obtenidos

hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del
sistema final.
Entonces, para validar los requerimientos hallados, se construyen
prototipos. Los prototipos son simulaciones del posible producto, que
luego son utilizados por el usuario final, permitindonos conseguir una
importante retroalimentacin en cuanto a si el sistema diseado con base a
los requerimientos recolectados le permite al usuario realizar su trabajo de
manera eficiente y efectiva. El desarrollo del prototipo comienza con la
captura de requerimientos. Desarrolladores y clientes se renen y definen
los objetivos globales del software, identifican todos los requerimientos
que son conocidos, y sealan reas en las que ser necesaria la
profundizacin en las definiciones. Luego de esto, tiene lugar un diseo
rpido. El diseo rpido se centra en una representacin de aquellos
aspectos del software que sern visibles al usuario (por ejemplo, entradas
y formatos de las salidas). El diseo rpido lleva a la construccin de un
prototipo.

6.5.

VALIDACIN DE REQUERIMIENTOS

La validacin de requerimientos trata de mostrar que estos realmente definen el

sistema que el cliente desea. Coincide parcialmente con el anlisis ya que este
implica encontrar problemas

con los requerimientos. La validacin de

requerimientos es importante

debido a que los errores en el documento de

requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son

descubiertas durante el desarrollo o despus de que el sistema est en uso. El coste
de arreglar un problema en los requerimientos haciendo un cambio en el sistema es
mucho mayor que repara los errores de diseo o los de codificacin. La razn de
esto es que un cambio en los requerimientos normalmente significa que el diseo y
la implementacin del sistema deben cambiar y que este debe probarse nuevamente.

24

Durante el proceso de validacin de requerimientos, se deben llevar a cabo

verificaciones sobre requerimientos en el documento de requerimientos. Estas
verificaciones comprenden:
1. Verificaciones de validez. Un usuario puede pensar que se necesita un
sistema para llevar a cabo ciertas funciones. Sin embargo, el razonamiento y
el anlisis pueden identificar que se requieren funciones adicionales o
diferentes. Los sistemas tienen diferentes stakeholders con diferentes
necesidades, y cualquier conjunto de requerimientos es inevitablemente un
compromiso en el entorno del stakeholders.
2. Verificacin de consistencia. Los requerimientos en el documento no deben
contradecirse. Esto es, no debe hacer restricciones o descripciones
contradictorias de la misma funcin del sistema.
3. Verificacin de completitud. El documento de requerimientos debe incluir
requerimientos que definan todas las funciones y restricciones propuestas
por el usuario del sistema.
4. Verificacin de realismo. Utilizando el conocimiento de la tecnologa
existe, los requerimientos deben verificarse para asegurar que se pueden
implementar. Estas verificaciones tambin deben tener en cuenta lo
propuesto y la confeccin de agendas para el desarrollo del sistema.
5. Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente y
el contratista, los requerimientos del sistema siempre deben redactarse de tal
forma que sean verificables. Esto significa que debe poder escribir un
conjunto de pruebas que demuestren que el sistema a entregar cumple cada
uno de los requerimientos especificados.
Pueden utilizarse, en conjunto o de forma individual, varias tcnicas de validacin
de requisitos:
1. Revisiones de requerimientos. Los requerimientos son analizados
sistemticamente por un equipo de revisores.
2. Construccin de prototipos. En este enfoque de validacin, se muestra un
modelo ejecutable del sistema a los usuarios finales y a los clientes. Estos
25

pueden experimentar con este modelo para ver si cumple sus necesidades
reales.
3. Generacin de casos de prueba. Los requerimientos deben de poder
probarse. Si las pruebas para estos se conciben como parte del proceso de
validacin, a menudo revela los problemas en los requerimientos. Si una
prueba es difcil o imposible de disear, normalmente significa que los
requerimientos sern difciles de implementar y deberan ser considerados
nuevamente. Desarrollar pruebas para los requerimientos del usuario antes
de que se escriba cdigo es un aparte fundamental de la programacin
extrema.
Las revisiones de requerimientos pueden ser informales o formales. Las
informales sencillamente implican que los contratistas deben tratar los
requerimientos con tantos stakeholders del sistema como sea posible. Es
sorprendente la frecuencia con la que finaliza la comunicacin entre los
desarrolladores y los stakeholders del sistema despus de la observacin de
requerimientos y que no exista confirmacin de que los requerimientos
documentados son realmente lo que dijeron que deseaban los stakeholders.
Antes de llevar a cabo una reunin para una revisin formal, muchos
problemas se pueden detectar simplemente hablando del sistema con los
stakeholders.
En la revisin formal de requerimientos, el equipo de desarrollo debe
conducir al cliente a travs de los requerimientos del sistema, explicndole
las implicaciones de cada requerimiento, el equipo de revisin debe verificar
cada

requerimiento

para

la

consistencia

adems

de

verificar

los

requerimientos como un todo para la completitud. Los revisores tambin

pueden verificar la:
1.
2.

Verificabilidad. Puede probarse el requerimiento de modo realista?

Comprensibilidad Las personas que adquieren el sistema o los

3.

usuarios finales comprenden correctamente el requisito?

Rastreabilidad. est claramente establecido el origen del
requerimiento? Puede tener que volver a la fuente del requerimiento
26

para evaluar el impacto del cambio. La rastreabilidad es importante

4.

ya que permite evaluar el impacto del cambio en el resto del sistema.

Adaptabilidad. Es adaptable el requerimiento? Es decir, puede
cambiarse el requerimiento sin causar efectos de gran escala en los
otros requerimientos del sistema?.

7. GESTIN DE REQUERIMIENTOS
Los requerimientos para sistemas software grandes son siempre cambiantes debido
a que el problema no puede definirse completamente, es muy probable que los
requerimientos del software sean incompletos. Durante el proceso de software, la
comprensin del problema por parte de los stakeholders est cambiando
constantemente. Estos requerimientos deben entonces evolucionar para reflejar esta
perspectiva cambiante del problema.
Adems, una vez que el sistema se ha instalado, inevitablemente surgen nuevos
requerimientos. Es difcil para los usuarios y clientes del sistema anticipar qu
efectos tendr el sistema nuevo en la organizacin. Cuando los usuarios finales
tienen experiencia con un sistema, descubren nuevas necesidades y prioridades:
La gestin de requerimientos es el proceso de comprender y controlar los cambios
en los requerimientos del sistema. Es necesario mantenerse al tanto de los
requerimientos particulares y mantener vnculos entre los requerimientos
dependientes de forma que se pueda evaluar el impacto de los cambios en los
requerimientos. Hay que establecer un proceso formal

para implementar las

propuestas de cambios y vincular estos a los requerimientos del sistema. El proceso

de gestin de requerimientos debera empezar en cuanto est disponible una versin
preliminar del documento de requisitos que cambian durante el proceso de
obtencin de requerimientos.
REQUERIMIENTOS DURADEROS Y VOLTILES

27

La evolucin de los requerimientos durante el proceso de ingeniera de

requerimientos y despus de que un sistema est en uso es inevitable. El desarrollo
de requerimientos software centra su atencin en las capacidades de este. Los
objetivos del negocio y otros sistemas de la organizacin. Conforme se va
desarrollando la definicin de los requerimientos, normalmente tiene una mejor
comprensin de las necesidades de los usuarios. Esto retroalimenta la informacin
del usuario, quien puede entonces proponer un cambio en los requerimientos.
Adems, especificar y desarrollar un sistema grande puede llevar varios aos.
Durante ese tiempo el entorno del sistema y los objetivos del negocio cambian, y los
requerimientos evolucionan para reflejar esto.
Desde una perspectiva evolutiva, los requerimientos se dividen en dos clases:
1. Requerimientos duraderos. Son requerimientos relativamente estables que

se derivan de la actividad principal de la organizacin y que estn

relacionados directamente con el dominio del sistema. Por ejemplo, en un
hospital siempre habr requerimientos que se refieren a los pacientes,
mdicos, enfermeras y tratamientos.
2. Requerimientos voltiles. Son requerimientos que probablemente cambien

durante el proceso de desarrollo del sistema o despus de que este se haya

puesto en funcionamiento. Un ejemplo seran las polticas gubernamentales
sobre sanidad.

8. GESTIN DEL CAMBIO DE LOS REQUERIMIENTOS

La gestin del cambio de los requerimientos (Figura 7.13) se debe aplicar a todos
los cambios propuestos en los requerimientos. La ventaja de utilizar un proceso
formal para gestionar el cambio es que todos los cambios propuestos son tratados de
forma consistente y que los cambios en el documento de requerimientos se hacen de
forma controlada. Existen tres etapas principales en un proceso de gestin de
cambio:

28

8.1.

Anlisis del problema y especificacin del cambio. El proceso

empieza con la identificacin de un problema en los requerimientos o,

algunas veces, con una propuesta de cambio especifica. Durante esta etapa,
el problema o la propuesta de cambio se analiza para verificar que es vlida.
Los resultados del anlisis se pasan al solicitante del cambio, y algunas
veces se hace una propuesta de cambio de requerimientos ms especfica.
8.2. Anlisis del cambio y clculo de costes. El efecto de un cambio
propuesto se valora utilizando la informacin de rastreo y el conocimiento
general de los requerimientos del sistema. El coste de hacer un cambio se
estima en trminos de modificaciones al documento de requerimientos y, si
es apropiado, al diseo e implementacin del sistema. Una vez que este
anlisis se completa, se toma una decisin sobre si se contina con el cambio
de requerimientos.
8.3. Implementacin del cambio. Se modifica el documento de
requerimientos y, en su caso, el diseo e implementacin del sistema. Debe
organizar el documento de requerimientos de modo que pueda hacer
cambios en el sin tener que hacer grandes reorganizaciones o redactar
nuevamente gran cantidad del mismo. Como sucede con los programas, los
cambios en los documentos se llevan a cabo minimizando las referencias
externas y haciendo las secciones del documento tan modulares como sea
posible. De esta manera, se pueden cambiar y remplazar secciones
individuales sin afectar a otras partes del documento.

Figura 7. Gestin de cambios en los requerimientos

Fuente: Ingeniera de Software 7ma. Ed., I. Somerville, p, 149

29

9. METODOS DE INGENIERA DE REQUERIMIENTOS

9.1 METODOLOGA ISAC
Caractersticas del mtodo
ISAC (Information Systems Work and Analysis of Changes)
Change Analysis and Activity Study = Analisis de cambio y estudio de
actividades. Information Systems work and Analysis of changes = Empleo de los
sistemas de informacin y anlisis de cambio. ISAC es un mtodo para el desarrollo
orientado a los clientes, no es muy adecuado para el desarrollo de sistemas de
control. ISAC fue desarrollado con el fin de asegurar que el negocio obtenga el
sistema de informacin que necesita. Para alcanzar este objetivo , ISAC se inicia
con un anlisis de los problemas de organizacin y trata de dar soluciones reales a
problemas reales. Si una solucin implica el desarrollo de un sistema de
informacin , entonces ISAC contina el desarrollo del sistema a travs de un
estudio detallado de las actividades que se apoya en el sistema.
Para que el sistema de entrega sea de acuerdo a las necesidades del negocio, el
anlisis del problema y el estudio de actividades se caracterizan por un alto grado de
participacin y cooperacin de los usuarios, desarrolladores y patrocinadores del
sistema de informacin. El papel de los desarrolladores en estas etapas es la de
facilitar el proceso por el cual los usuarios y patrocinadores analizan sus problemas
y llevan a cabo un estudio de las actividades .
Objetivo
Garantizar que las empresas obtengan el sistema de informacin que

requieren.
Definir los requerimientos de un sistema de informacin
Empieza con el anlisis de problemas organizacionales para

encontrar las soluciones.

Si la solucin involucra el desarrollo de un Sistema de Informacin
continua con el estudio detallado de las actividades de la empresa que
sern cubiertos por el sistema.

Para incrementar el ajuste entre el sistema y necesidades de la empresa, tanto para el

problema analizado y actividades estudiadas se caracterizan por la participacin y
cooperacin de usuarios, desarrolladores y responsables del S.I. El desarrollador
30

ayuda a usuarios a analizar sus problemas y realizar un estudio de las actividades,

identificando conflictos y diferencias entre funciones.
Cuestiones
1. Anlisis de Cambio
Cual es objetivo de la organizacin?
Cuan flexible es la organizacin respecto a los cambios?
2.
Estudio de las actividades
Qu actividades debemos reagrupar en el sistema de informacin
(organizar)
Que propiedades tiene el sistema de informacin
Anlisis de la informacin
Qu entradas y salidas tiene el sistema de informacin
Cuales son los requerimientos cuantitativos del sistema de informacin
Implementacin
Qu tecnologa usamos para el sistema de informacin (hardware, software,

3.
3.

flujo de informacin)
Que actividades del sistema de informacin son manuales y cuales son
automticas
Repuestas del mtodo ISAC
1. Anlisis de Cambio
1. Lista de problemas
2. Lista de propietarios de los problemas
3. Analizar los problemas
4. Realizar el modelo de actividad actual
5. Analizar los objetivos
6. Definir las necesidades de cambio
7. Generar alternativas de cambio
8. Realizar el modelo de actividad de situaciones esperadas
9. Evaluar alternativas de cambio
Seleccionar el modelo de actividad
2. Estudio de las actividades
Descomponer el modelo de actividad seleccionado en subsistemas de

informacin
Elaborar el modelo de actividad seleccionada
Identificar subsistemas de informacin
Analizar elementos automatizables
Elaborar modelos de actividades antes de cada sistema de informacin

Actividades
31

Analizar cada elemento del sistema de informacin

Analizar la contribucin de cada elemento al logro del objetivo de cambio
Generar niveles de ambicin para el sistema de informacin
Probar exhaustivamente cada nivel del sistema de informacin
Realizar un anlisis de costo/beneficio de los niveles
Elegir un nivel
Coordinar el sistema de informacin
Definir las interfaces entre los elementos del sistema
Asignar prioridad a cada elemento del sistema de informacin

3. Anlisis de la informacin: para cada elemento del sistema:

Especificar las relaciones entre entradas y salidas para el S.I.
Especificar la estructura de datos para S.I.
Especificar la estructura de procesos para el S.I.
3. Implementacin
HARDWARE
SOFTWARE
PLATAFORMA DE DESARROLLO

9.2 METODOLOGA ESPIRAL

En este modelo se asume una naturaleza iterativa del proceso y la dificultad de
establecer un punto de terminacin del mismo, dado que los requerimientos nunca
llegarn a ser perfectos. El modelo asume que existe la actividad de gestin de
requerimientos, que se realiza durante todo el proceso y que se encarga de gestionar
la obtencin incremental de los requerimientos y los inevitables cambios a los que
estn sujetos (Somerville, 2005).

32

Figura 8. Esquema del modelo Espiral

Fuente: Somerville 2005

Como se puede observar en la figura 8, este ciclo en espiral contina repitiendo las
fases hasta que llegue un momento en que la negociacin de requerimientos se
considera finalizada, pues no se detectan ms requerimientos que incluir y los que
ya se han incluido no presentan conflictos ni contradiccin. En ese momento, se
dara por finalizado el documento de requerimientos y se continuara con el resto del
proceso de desarrollo. Si todava quedaran requerimientos por identificar o negociar
para resolver conflictos, se dara otra vuelta a la espiral (Somerville, 2005).

9.2 METODOLOGA DORCU

La metodologa DORCU (Documentacin de Requerimientos Centrada en el
Usuario), consta de las siguientes etapas:
Elicitacin de Requerimientos.
Esta es la etapa en donde se adquiere el conocimiento del trabajo del
cliente/usuario, se busca comprender sus necesidades y se detallan las
restricciones medioambientales. Como resultado de las acciones realizadas
se tiene el conjunto de los requerimientos de todas las partes involucradas.
Anlisis de Requerimientos.
33

En esta etapa se estudian los requerimientos extrados en la etapa previa a los

efectos de poder detectar, entre otros, la presencia de reas no especificadas,
requisitos contradictorios y peticiones que aparecen como vagas e
irrelevantes. El resultado de haber llevado a cabo las tareas que involucran
estos trminos puede, en ms de una oportunidad, hacer que se deba regresar
a la primera etapa, a los efectos de eliminar todas las inconsistencias y
falencias que se han detectado. En esta etapa ya se realizan aproximaciones a
un lenguaje tcnico.
Especificacin de Requerimientos . Partiendo de lo elaborado en la etapa
anterior tales como funciones, datos, requerimientos no funcionales,
objetivos,

restricciones

de

diseo/implementacin

costos,

independientemente de la forma en que se realice, esta etapa es un proceso

de descripcin del requerimiento. Si se presentan dificultades para
especificar un requerimiento se debe volver a la etapa anterior que se crea
conveniente.
Validacin y Certificacin de los Requerimientos. Esta etapa final se
nutre de las anteriores y realiza la integracin y validacin final de lo
obtenido en

cada una de las etapas anteriores dando, como resultado final,

el Documento de Requerimientos. Este documento no es uno solo sino que,

mnimo,

existen dos que son isomrficos entre s: uno destinado al

cliente/usuario a

los efectos de la certificacin de los Requisitos y el

otro tcnico, orientado a

nutrir las restantes etapas de la Ingeniera de

Software. Y, al igual que en el

necesidad de retornar a la

caso anterior, su resultado puede ser la

especificacin e incluso a la Elicitacin;

iterando entre etapas y sin perder

contacto con el cliente/usuario.

34

Figura 9. Esquema de la Metodologa Flexible DORCU

Fuente: Metodologa DoRCU para la Ingeniera de Requerimientos, p, 214

10.REVISIN DE HERRAMIENTAS EN LA INGENIERA DE

REQUISITOS
Las herramientas CARE (Computer-Aided Requirements Engineering) facilitan el
trabajo de los analistas permitiendo la definicin, organizacin, almacenamiento y
gestin de los requisitos. A travs de la gestin de trazas, estas herramientas tambin
ayudan a evaluar el impacto de los cambios en los requisitos en los procedimientos,
costes y personal. Las herramientas CARE deben proporcionar operaciones de
creacin, edicin y recuperacin de requisitos y gestin de trazas, adems de
funcionalidades como las siguientes...
Informes de alto, como nmero de requisitos, nmero de requisitos de alto
nivel, coste estimado de los cambios propuestos, requisitos que han
cambiado, estado de desarrollo del proyecto (nmero de requisitos

implementados y/o aprobados).

Plantillas para documentacin del proyecto.
Integracin con otras herramientas CASE, y posibilidad de construir
extensiones (add-in) personalizadas.
35

Algunas herramientas CARE estn centradas en documentos, como por ejemplo,

IBM Rational Requisite Pro, que opera sobre el procesador de textos Word (aunque
tambin mantiene un repositorio de requisitos). Otras CARE estn basadas

en

un repositorio de requisitos (como por ejemplo Telelogic Doors o la espaola IRqA,

de TCP Sistemas e Ingeniera).

Figura 10. Resumen de la comparativa de herramientas CARE

Fuente: INCOSE, The International Council on Systems Engineering Requirements
Management Tools Survey (http://www.incose.org). 2006.

36

10.1

RequisitePro

RequisitePro es la herramienta que ofrece Rational Software para

tener un mayor control sobre los requerimientos planteados por el
usuario y todos aquellos requerimientos tcnicos o nuevos
requerimientos de usuario que surjan durante el ciclo de vida del
proyecto. En RequisitePro los requerimientos se encuentran
documentados bajo un esquema organizado de documentos; estos
esquemas cumplen completamente con los estndares requeridos por
algunas de las instituciones a nivel mundial ms reconocidas en el
desarrollo de software, tales como: IEEE (Instituto de Ingenieros
Elctricos y Electrnicos), ISO, CMM (Modelo de Capacidad de
Madurez) y por el RUP (Proceso Unificado Racional) Esta
herramienta se integra con aplicaciones para la administracin de
cambios, herramientas de modelado de sistemas y con herramientas
de pruebas. Esta integracin asegura que los diseadores conocen los
requerimientos del usuario, del sistema y del software en el momento
de su desarrollo. El desarrollo de software es una tarea de equipo, de
tal forma, es crtico que todos los miembros del equipo posean un
entendimiento compartido de la visin de sus proyectos, metas,
especificaciones y requerimientos; pero, cmo puede conseguirse
cuando los equipos se encuentran geogrficamente distribuidos y
funcionalmente aislados, no pudiendo comunicarse entre s en tiempo
y forma? La solucin a esta necesidad es IBM Rational RequisitePro.
IBM Rational RequisitePro es una solucin fcil de usar, es una
herramienta de administracin de requerimientos que le permite al
equipo crear y compartir sus requerimientos utilizando mtodos
familiares basados en documentos potenciados por la aplicacin de
las capacidades de una base de datos, tales como la trazabilidad y
37

anlisis de impacto. El resultado es una mejor comunicacin y

administracin de requerimientos con una mayor probabilidad de
completar los proyectos en tiempo, dentro del presupuesto y
superando las expectativas. Los proyectos exitosos comienzan con
una buena administracin de requerimientos, cuanto ms efectiva sea
su ejecucin, mayor ser el resultado en calidad y satisfaccin del
cliente. Segn la promocin hecha en Internet mediante la pgina
Web para esta herramienta, algunas de sus ventajas son:
Un producto potente y fcil de utilizar para la gestin de
requisitos y casos de uso que propicia una mejor
comunicacin, mejoras en el trabajo en equipo y reduce el
riesgo de los proyectos.
Combina la interfaz conocida y fcil de utilizar de los
documentos de Microsoft Word con potentes funciones de
base de datos para conseguir la mxima eficacia en anlisis y
consulta de requisitos.
Proporciona a los equipos la posibilidad de comprender el
impacto de los cambios.
Garantiza que todos los componentes del equipo estarn
informados de los requisitos ms actuales para asegurar la
coherencia.
Proporciona acceso basado en Web para los equipos
distribuidos.
La ventaja de utilizar herramientas como la de RequisitePro, es que el
desarrollo de software se ve beneficiado de muchas maneras, y en el
caso de la ingeniera de requerimientos, le ayuda notablemente, la IR
constituye una de las etapas ms importantes a tomar en cuenta en el
ciclo de desarrollo de software, ya que en ella se definen los
requerimientos con los que debe de contar el software; e incluso,
podra llegar a determinar la viabilidad de implementar ese software
no es del todo posible, y poder cancelar a tiempo un desarrollo no
productivo.

11.CONCLUSIONES
38

 El xito de un proyecto de desarrollo de software, depender mucho si se

realiza bien la adquisicin y administracin de los requerimientos, ya que es
el pilar fundamental para continuar con los pasos posteriores al desarrollo de
software.
Empleando herramientas CARE este trabajo ser menos dificultoso ya que
son un apoyo en la administracin de requerimientos, logrando as mejores
resultados en comparacin a realizarlos manualmente.
Cabe recalcar tambin que para la adquisicin de requerimientos no existe
una sola formula un mtodo, todos los mtodos sern muy tiles
dependiendo de la magnitud del proyecto.

12. BIBLIOGRAFA
1. La ingeniera de requerimientos y su importancia en el desarrollo de
proyectos de software(Michael Arias Chaves).
2. Ingeniera del Software Sptima Edicin IAN SOMMERVILLE.
3. Ingeniera de Requerimiento: Ing. Mauricio Mendoza Lozano.
4. M. Manies & U. Nikual. La Elicitacin de Requisitos en el contexto de un
proyecto software.
5. INSTITUTE FOR ELECTRONICS AND ELECTRICAL ENGINEERS.
Glosario estndar de la terminologa de la ingeniera de software estndar
6. SOMMERVILLE, Ian y SAWYER, Peter. Requirements engineering: A good
practice guide. 3 ed. Chinchester, Inglaterra: John Wiley&Sons Ltd., 2000.
7. SOMERVILLE, Ian. Ingeniera de software. 7 ed. Mxico: Addison Wesley,
2004.
8. La ingeniera de requerimientos y su importancia en el desarrollo de
proyectos de software( Michael Arias Chaves).
9. Monografa Ingeniera de Requerimientos, Ma. de Lourdes Peres Huebe
2005.
10. ISAC (R.J. Wieringa, Requirements Engineering, Editorial John Wiley
& Sons, 1996).
11. INCOSE, The International Council on Systems Engineering Requirements
Management Tools Survey (http://www.incose.org). 2006.
39

12. Pressman, Roger S. 2006, Ingeniera del Software: Un enfoque prctico,

Sexta edicin, Mxico DF, Editorial McGraw Hill.

40