1. Gestión de Requerimientos como disciplina
en el modelamiento del negocio basado en la
metodología del Rational Unified Process
Lucio César Rodríguez Reyes1*, Danher Huamán Camas2,
1,2
*
Facultad de Ingeniería y Arquitectura, Universidad Peruana Unión
Corresponde autor:
Dirección: Universidad Peruana Unión, , Jr. Los Mártires 218 , Morales, San Martin, San Martin
E-mail: sheshin93@gmail.com, E-mail: da4846@gmail.com.
Teléfono: 976284351

2. Resumen
La presente investigación tiene como propósito mostrar los fundamentos teóricos de la
gestión de requerimientos en el modelamiento del negocio bajo metodología del RUP.
Entiéndase como un requerimiento una condición o necesidad de un usuario para resolver
un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en
un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u
otro documento formal. Una representación documentada de una condición o capacidad.
(Senn, 1992). ¿Cómo influyen los requerimientos en el modelamiento del negocio? Los
requerimientos ayudan a definir un acuerdo formal de lo que se debe hacer, fronteras del
proyecto, proporciona las bases para la planificación de las iteraciones y definir interfaces
basándose en las necesidades. Los requerimientos pueden dividirse en requerimientos
funcionales y requerimientos no funcionales. Los
Requerimientos cumple un papel
primordial en el proceso de producción de software, ya que enfoca un área fundamental: la
definición de lo que se desea producir. Su principal tarea consiste en la generación de
especificaciones correctas que describan con claridad, sin ambigüedades, en forma
consistente y compacta, el comportamiento del sistema; de esta manera, se pretende
minimizar los problemas relacionados al desarrollo de sistemas (fowler, 1999).
Palabras clave: requerimiento; software; casos de uso; sistema.

3. 1.
Introduction
Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar
Requisitos), definir los límites del sistema, y una interfaz de usuario, realizar una
estimación del costo y tiempo de desarrollo. Esta situación ha llevado a comprender que,
debido a la complejidad y exigencia de los procesos a automatizar, se requiere de grandes
cambios en el proceso de producción de los software y se ha hecho imprescindible la
práctica de nuevos métodos, que permitan coordinar, supervisar y establecer el trabajo en
equipo entre el grupo de desarrollo de cada proyecto de software y sus clientes, como vía
para lograr que los requisitos identificados sean viables, adecuados y permitan decidir, con
el mayor por ciento de exactitud posible, qué se desea y qué es posible automatizar en
definitiva (Bracker, 1990).
Estas prácticas se hacen efectivas por medio de las etapas de Modelado del negocio y
Gestión de requisitos, las fases primarias del proceso de desarrollo de un sistema
automatizado. En general, cada vez, existe un reconocimiento mayor de su importancia y
los riesgos en que se incurre si estas se cumplen de manera incorrecta o insuficiente. Son
estas actividades las que definen la dirección y el alcance del proyecto y se realizan según
los intereses de la entidad encargada del desarrollo del producto final, es por ello que, amén
de la existencia de metodologías reconocidas, como RUP (Rational Unified Process),
algunas organizaciones dedicadas a la actividad de informatización han creado
metodologías propias internas según sus intereses de captura de información (Saiedian,
1999).

4. Con el modelado de negocio se logra "conocer" la organización: misión, funciones,
estructura, expertos, tecnología, debilidades, fortalezas; comprender el entorno en el que va
a funcionar el sistema, identificar sus procesos, la información, los actores participantes en
dichos procesos y los papeles que representan cada uno de ellos, con respecto a cada
porción de la información (Oberg, 1998).
Una vez identificados los procesos y flujo de actividades para producir un resultado de
valor, es posible determinar su viabilidad, si son los correctos o si necesitan alguna
modificación, claro, sin llegar a un análisis tan amplio como el que pudiera comprender una
consultoría de procesos. Igualmente, es posible determinar la localización de la
información; si existe duplicidad en ella; así como el acceso innecesario a la información
que no corresponde o la carencia de otra que sí es necesaria; se puede conocer también la
responsabilidad de cada actor la función que asume una persona, sistema o entidad que
interactúa con el sistema
con respecto a la información que utiliza para realizar su
actividad laboral y el rol de conjunto de funciones, normas, comportamientos y derechos
definidos para un cliente registrado que desempeña en el sistema.
Con la disciplina de Requerimientos el beneficio será uniforme, tendrá un aporte
tecnológico, social y Espiritual.
Además se presenta el fundamento teórico de la disciplina de gestión de requerimientos,
metodología, tipos formas de adquirir requerimientos, aportes y conclusiones.

5. 2.
Metodología
El RUP se divide en varias disciplinas de ingeniería y de soporte como se muestra en la
tabla 1.
Tabla 1- Metodología Rational Unified Process.
Disciplinas de ingeniería:
1.Disciplina de modelaje del negocio
Disciplinas de soporte:
2.Disciplina de requerimientos
1. Disciplina de administración de la
configuración y control de cambios
3.Disciplina de análisis y diseño
2. Disciplina de administración de proyectos
4.Disciplina de implementación
3. Disciplina de entorno y soporte del
ambiente de desarrollo
5.Disciplina de pruebas
6.Disciplina de despliegue
En este artículo nos enfocaremos especialmente en la disciplina de requerimientos.
2.1. Tipos de Requerimientos
2.1.1. Funcionales
Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en
términos de importancia para el usuario y no sólo en términos de funciones que sería bueno
contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que
proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos
funcionales del sistema (Quispe, 2011) .
2.1.2. No Funcionales
La arquitectura de un sistema es la organización o estructura de sus partes más
relevantes, lo que permite tener una visión común entre todos los involucrados

6. (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para
controlar el desarrollo. La arquitectura involucra los aspectos estáticos y dinámicos más
significativos del sistema, está relacionada con la toma de decisiones que indican cómo
tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la
definición de la arquitectura debe tomar en consideración elementos de calidad del sistema,
rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante
todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software,
sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como
sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del
sistema (Approach 2007).
2.2. Forma Adquirir los Requerimientos
2.2.1. Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información proveniente de
personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el
cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un
sistema.
Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y
abstractas que pueden realizarse al inicio del proyecto para obtener información sobre
aspectos globales del problema del usuario y soluciones potenciales.
Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y
experiencias generales, o para explorar un proceso o problema.

7. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios,
procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas.
Del Usuario: ¿Quién es el cliente?, ¿Quién es el usuario?, ¿Son sus necesidades
diferentes?, ¿Cuáles son sus habilidades, capacidades, ambiente?
Del Proceso: ¿Cuál es la razón por la que se quiere resolver este problema?, ¿Cuál es el
valor de una solución exitosa?, ¿Cómo usted resuelve el problema actualmente?, ¿Qué
retrasos ocurren o pueden ocurrir?
Del Producto: ¿Qué problemas podría causar este producto en el negocio?, ¿En qué
ambiente se usará el producto?, ¿Cuáles son sus expectativas para los conceptos fácil de
usar, confiable, rendimiento?, ¿Qué obstáculos afectan la eficiencia del sistema?
El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su
preparación para la misma. Los analistas necesitan ser sensibles las dificultades que
algunos entrevistados crean durante la entrevista y saber cómo tratar con problemas
potenciales. Asimismo, necesitan considerar no sólo la información que adquieren a través
del cuestionario y la entrevista, sino también, su significancia.

8. 2.3. Aporte de los Requerimientos
2.3.1. Aporte Tecnológico
La documentación de requerimientos es una de las más importantes partes del
proceso de desarrollo de software, pero es, a la vez, una de las que cuenta con pocas
herramientas de soporte tecnológico en la actualidad, aumentando el tiempo y costos del
proyecto. A su vez es una etapa donde inevitablemente existe contradicciones y
ambigüedad que atentan contra el correcto comienzo de la vida del software (European
Software Process Improvement Training Initiative, 1996).
Las causas primarias de realizar una incorrecta conceptualización del problema es
cuando el desarrollador de software tiene situaciones en que es escaso el conocimiento
acerca del dominio de aplicación y el dominio de aplicación, donde se implantará el
software, puede ser complejo.
2.3.2. Aporte Social
Involucrar al grupo para compartir sus experiencias. Mejorar las dificultades que
puede tener una persona, hasta una organización, observando las debilidades y dificultades
que tiene, dando opiniones de solución, pasando por un proceso, lo que el cliente quiere,
pasando a formar unos requerimientos más del sistema.
Del mismo modo organiza mejor el tiempo y costo de presupuesto.

9. 2.3.3. Aporte Espiritual
A través de la historia el ser humano se ha preocupado desde el punto de vista moral y
espiritual. Como aceptar lo bueno, lo justo, lo bello etc., y como contraposición a esto lo
malo, lo injusto, lo feo, lo perjudicial lo que ha sido una interrogante desde que el hombre
comenzó a organizarse en las sociedades para mejorar este aspecto tan importante.
Los requerimientos ayudan en los siguientes aspectos.
- La organización es una muestra de ella, el buen trabajo en equipo, tiempos
establecidos, La equidad de trabajo, La disposición para ayudar al cliente de la mejor
manera posible y sobre todo dan un producto de buena calidad. Todo lo mencionado ayuda
a la formación del buen carácter del ser humano y da un buen testimonio del mismo.

10. 3.
Conclusiones
A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho
que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que
deben ser mejorados, tales como la integración de requerimientos funcionales y no
funcionales, la evaluación de especificaciones alternativas.
Cada actividad y técnica de Requerimientos utilizada individualmente, dará diferentes
soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el
área del problema son el mismo. Por esta razón, considero que no existe un modelo de
proceso ideal para los Requerimientos; encontrar el método o la técnica perfecta es una
ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.
Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra
a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el
proceso de Requerimientos no depende solamente de la forma en cómo se percibe el
problema, sino también, del nivel de experiencia que tengan los involucrados.

11. Referencias
Senn, A. (Ed.,1992). Análisis y Diseño de Sistemas de Información. México: McGraw
Hill..
Fowler, M. (1999). UML Gota a Gota. Madrid: Addison Wesley Longman.
Brackett, J W. (1990). Software Requirements and Software Engineering Institute
Education Program. Estados Unidos: Washinton
Saiedian, H.; Dale, R. (1999) "Requirements Engineering: Making the connection between
the software developer and customer". Department of Computer Science – University
of Nebraska.
Oberg, R; Probasco L; Ericsson, M. (1998). Applying Requirements Management with
Use Cases. Rational Software Corporation.
Hofmann, H. (1993) . Requirements Engineering. Institute for Informatics – University of
Zurich.
Malan, R.(1999). Functional Requirements and Use Cases. Hewlette-Packard Company.
Lutor.-K.-(2008)IEEE
Task
Force
on
Requirements
Engineering.
http://www.shu.ac.uk/tfre/web.links.html. (consultado el 25 de noviembre de 2013)
Smith, F. Software Engineering Resources by Roger S. Pressman & Associates Inc.
http://www.rspa.com/spi/index.html. (consultado el 25 de noviembre de 2013)
Wilian, G. Ingeniería de Software. http://www.soi.city.ac.uk/gespan/sw_group_pub.html.
(consultado el 28 de noviembre de 2013)