Unidad 1. Ingeniería de Requerimientos.

Competencias.
Las competencias se definen como un conjunto de habilidades que están fundamentalmente
referidas a las características del comportamiento general del sujeto en el puesto de trabajo; y
tienen distintos grados de evaluación, a través de la práctica y la capacitación, este grado puede ir
aumentando. [1]

 Competencias Genéricas: Son de carácter más universal y ligadas al comportamiento más

superficial del individuo, quedando excluidas sus habilidades más específicas ligadas a una
actividad particular.
 Competencias Específicas: Conoce y discrimina los tipos de requerimientos para un
proyecto de software.
 Competencias Instrumentales: Capacidad de análisis y síntesis, capacidad de organizar y
planificar, comunicación oral y escrita en su propia lengua, conocimiento de una segunda
lengua, habilidades de gestión de información, solución de problemas, toma de
decisiones.
 Competencias Interpersonales: Resultan relacionadas con el éxito en las tareas que
suponen contacto interpersonal con otras personas para el correcto desempeño del
puesto de trabajo.
 Competencias Sistémicas: Suponen destrezas y habilidades relacionadas con la
comprensión de la totalidad de un conjunto. Requieren una combinación de imaginación,
sensibilidad y habilidad que permite ver cómo se relacionan y conjugan las partes en un
todo.

Realidad de los Proyectos de Software.

GAO 1979.
En 1979, la Oficina de Cuentas del Gobierno Norteamericano (Government Account Office, GAO)
realizó un estudio [GAO, 1979] seleccionando nueve proyectos de desarrollo de software para el
gobierno norteamericano cuyos contratos sumaban una cantidad total de 6.800.000 dólares.

De esta cantidad, sólo 119.000 dólares correspondían a un proyecto que se había utilizado tal
como se había entregado. Dicho proyecto se trataba de un preprocesador de COBOL, por lo que
era un problema relativamente simple cuyos requerimientos eran comprendidos por clientes y
desarrolladores y que además no cambiaron durante el desarrollo.

El resto de los 6.8 millones de dólares se distribuyeron como puede verse, en la que puede
destacarse el enorme porcentaje de dinero invertido en proyectos cancelados o no satisfactorios.

1.- Entregado pero nunca usado

satisfactoriamente
2.- Pagado pero no entregado
3.- Usado pero reelaborado o abandonado
después
4.- Usado después de cambios
5.- Usado tal como se entregó

1
Unidad 1. Ingeniería de Requerimientos.

GRUPO STANDISH.
La investigación del Grupo Standish [2] muestra que el 31.1% de los proyectos serán cancelados
antes de que se completen. El 52.7% de los proyectos costarán 189% más de sus estimaciones
originales y los costos de oportunidad perdidos son de miles de millones de dólares.

1.- Terminado y operativo, pero fuera de

plazo, fuera de presupuesto, sin satisfacer
todos los requisitos

2.- Cancelado desde el desarrollo

3.- Terminado dentro de plazo y presupuesto

cumpliendo todos los requisitos

Factores de Fracaso.
Los principales factores de daño o cancelación de los proyectos tecnológicos se observan en la
Tabla 1

Factores de Daño o Cancelación %

Requerimientos incompletos 13.1
Deficiencia en el involucramiento del usuario 12.4
Deficiencia de recursos 10.6
Expectativas no realistas 9.9
Deficiencia en soporte ejecutivo 9.3
Cambios en los requerimientos 8.7
Deficiencia en la planeación 8.1
Ya no se necesita más 7.5
Deficiencia en la administración de TI 6.2
Desconocimiento en tecnología 4.3
Otros 9.9
Tabla 1. Factores de Fracaso.

Los factores que afectan el éxito de los proyectos según Baker, Murphy y Fisher, citados por
McManus [3], quienes estudiaron 650 proyectos en los Estados Unidos son los siguientes:

 Compromiso con el proyecto en el establecimiento de cronogramas, presupuestos y

objetivo de desempeño técnicos.
 Frecuente retroalimentación de la organización patrocinadora.
 Frecuente de retroalimentación del cliente.
 Compromiso del cliente, del patrocinador, comprometido en el establecimiento de
cronogramas, presupuestos y objetivo de desempeño técnicos.
 Estructura de la organización adecuada al equipo del proyecto.
 Participación del equipo del proyecto en la determinación del cronograma y los
presupuestos.

2
Unidad 1. Ingeniería de Requerimientos.

 Entusiasmo del patrocinador.

 Deseo del patrocinador de crear las capacidades internas.
 Procedimientos de control adecuados, especialmente en relación con los cambios.
 Soporte público entusiasta.

Visión del Proyecto.

Figura 1. Como ve cada encargado un proyecto de software.

Ingeniería de Software.
Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y
mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los

problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la
ingeniería de software.

 Mejorar la calidad de los productos de software.

 Aumentar la productividad y trabajo de los ingenieros del software.
 Facilitar el control del proceso de desarrollo de software.

3
Unidad 1. Ingeniería de Requerimientos.

 Suministrar a los desarrolladores las bases para construir software de alta calidad en una
forma eficiente.
 Definir una disciplina que garantice la producción y el mantenimiento de los productos
software desarrollados en el plazo fijado y dentro del costo estimado.

La primera etapa de la metodología de la ingeniería de software es el Análisis de Requerimientos.

[4]

Requerimientos.

¿Qué es un requerimiento?
"Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un
objetivo". (IEEE).

"Una condición o capacidad que debe ser conformada por el sistema". (RUP).

Tipos de Requerimientos.
Los requerimientos de software pueden dividirse en 2 categorías: requerimientos funcionales y
requerimientos no funcionales.

Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar,
describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es
importante que se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos
requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la
lógica y gran parte del código del sistema.

Los requerimientos no funcionales tienen que ver con características que de una u otra forma
puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de
usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estándares, etc.

Características.
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben
ser reformulados hasta hacerlo.

 Necesario: Lo que pida un requerimiento debe ser necesario para el producto.

 No ambiguo: Texto claro, preciso y tener una única interpretación posible.
 Conciso: Debe escribirse en un lenguaje comprensible en lugar de uno de tipo técnico.
 Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento
diferente, ni con parte de otro.
 Completo: Debe contener en sí mismo toda la información necesaria.
 Alcanzable: Debe ser un objetivo realista, posible de ser alcanzado con el dinero, el
tiempo y los recursos disponibles.
 Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue
satisfecho o no, mediante análisis. [5]

4
Unidad 1. Ingeniería de Requerimientos.

Dificultades para definir los requerimientos.

Durante la etapa de especificación de requerimientos se pueden presentar muchos inconvenientes
los cuales son importantes de identificar y prevenir, a continuación se presenta un listado con los
problemas más comunes en este proceso:

 Los requerimientos no son obvios y vienen de muchas fuentes.

 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

Ingeniería de Requerimientos.
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado
Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una
especificación de requisitos de software correcta y completa.

A continuación se darán algunas definiciones para ingeniería de requerimientos:

"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa,

consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes
involucradas y en dónde se describen las funciones que realizará el sistema". (Boehm 1979)

"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 combinación de métodos, herramientas y
actores, cuyo producto es un modelo del cual se genera un documento de requerimientos". (Leite
1987)

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los

requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los
cambios de requerimientos, entre los clientes y el equipo del proyecto". (Rational Software)

Importancia de la Ingeniería de Requerimientos.

 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 estimación 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;
especialmente aquellas decisiones tomadas durante la RE.

5
Unidad 1. Ingeniería de Requerimientos.

 Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un
conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño,
etc.).

 Mejora la comunicación entre equipos: La especificación de requerimientos 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 ingeniería de requerimientos obliga al cliente a

considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del
problema, por lo que se le involucra durante todo el desarrollo del proyecto. [6]

Proceso de Ingeniería de Requerimientos.

Es muy importante definir cuál es el proceso de ingeniería de requisitos ya que esto nos va a servir
para la obtención correcta de los requerimientos.

Figura 2. Diagrama que muestra el proceso de IR.

 Estudio de viabilidad: Este permitirá rendir un informe tanto al equipo de desarrollo del
proyecto como al usuario o cliente, donde se verificará si el proyecto vale la pena
desarrollarlo. Es de vital importancia para la satisfacción de los objetivos del negocio.

 Captura y Análisis: En esta fase el desarrollador o su equipo de desarrollo entran en

contacto con el usuario final o con el cliente para determinar el alcance del proyecto o del
sistema que se desea construir, además, se debe identificar cuáles son los servicios que
prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los
objetivos esperados.

 Especificación: Aquí se debe obtener un documento de especificación de requisitos, en

cual se llega a definir de una forma completa, precisa y verificable cada uno de los

6
Unidad 1. Ingeniería de Requerimientos.

requerimientos o necesidades que debe satisfacer el sistema a desarrollar, además de sus

respectivas restricciones (software, hardware).

 Validación: Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos
definen el sistema o proyecto que se va a construir y que desea el cliente. En esta etapa
solamente entran aquellos requisitos que se mencionaron ya en la especificación.

 Gestión: Se realiza la comprensión y control de los cambios de cada una de los requisitos,
sean estos requisitos estables (corresponden al estado del sistema) o volátiles
(representan eventos que hacen que el sistema realice una función dada). [7]

Herramientas para Ingeniería de Requerimientos.

Existen varias técnicas para la IR. Es importante resaltar que estas técnicas pueden ser aplicables a
las distintas fases del proceso de la IR, tomando en cuenta las características propias del proyecto
en particular que se esté desarrollándose para aprovechar al máximo su utilidad.

 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.

Comúnmente, los encuestados son usuarios de los sistemas existentes o usuarios en

potencia del sistema propuesto. En algunos casos, son gerentes o empleados que
proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de
esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

Tips para realizar entrevistas: Utilizar una técnica de rombo; de preguntas cerradas,
abiertas y cerradas. Observación del mundo (STROBE). Tener un guión flexible
(improvisación).

 Sistemas existentes. Consiste en analizar distintos sistemas ya desarrollados que estén

relacionados con el sistema a ser construido. Por un lado, se puede analizar las interfaces
de usuario, observando el tipo de información que se maneja y cómo es manejada, por
otro lado también es útil analizar las distintas salidas que los sistemas producen, porque
siempre pueden surgir nuevas ideas.

 Lluvia de ideas (Brainstorm). Este es un modelo que se usa para generar ideas. La
intención en su aplicación es la de generar la máxima cantidad posible de requerimientos
para el sistema. La intención de este ejercicio es generar, en una primera instancia,
muchas ideas; que luego serán eliminadas de acuerdo a distintos criterios.
 
 Técnica del aprendiz. El aprendiz es el analista mientras que el maestro es el
cliente/usuario. El aprendiz se sienta con el maestro con el objetivo de aprender a través
de la observación y de la realización de preguntas.

 Prototipos. Durante la actividad de extracción de requerimientos, puede ocurrir que

algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber
entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual

7
Unidad 1. Ingeniería de Requerimientos.

puede llevar a un desarrollo no eficaz del sistema final. Para validar los requerimientos
hallados, se construyen prototipos.

Los prototipos son simulaciones del posible producto, que luego son utilizados por el
usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si
el sistema diseñado con base a los requerimientos.

 Casos de Uso. Los casos de uso son una técnica para especificar el comportamiento de un
sistema. En el sitio wikipedia.org, define a un caso de uso como:
“Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema
en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de
casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema
mediante su interacción con los usuarios y/o otros sistemas”
(http://es.wikipedia.org/wiki/Caso_de_uso).

Los casos de uso permiten entonces describir la posible secuencia de interacciones entre
el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor,
es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un
evento inicial desde un actor hacia el sistema. [8]

Definición de Requerimientos.
 Debe especificar el comportamiento externo del sistema de forma que los requerimientos
no sean definidos usando un modelo computacional.
 Incluyen requerimientos funcionales y no-funcionales.
 Los Requerimientos funcionales son estatutos de servicios que el sistema debe proveer.
 Los Requerimientos no-funcionales son restricciones son los servicios y las funciones
ofrecidas por el sistema.

Especificación de requerimientos.
 La especificación añade detalles a la definición de los requerimientos, por lo que debe ser
consistente con estos.
 Usualmente presentada mediante modelos de sistema los cuales son desarrollados
mediante el análisis de requerimientos. Estos modelos pueden definir parte del sistema a
desarrollarse.
 A menudo escritos en lenguaje natural, lo cual puede causar problemas.

SRS.
En la práctica es común describir los requerimientos en un documento llamado Especificación de
Requerimientos del Software (SRS - Software Requirements Specification).

Un SRS sirve para:

 Comunicar de manera precisa los requerimientos, objetivos y presunciones del dominio.
 Base para estimación (tamaño, costo, tiempo) y planificación de proyecto.
 Base para evaluación de producto final.
 Verificación y validación.
 Base para el control de cambios.

8
Unidad 1. Ingeniería de Requerimientos.

Un SRS deberá abarcar:

 Funcionalidad. ¿Qué es lo que el software hace?

 Interfaces externas. ¿Cómo debe interactuar con gente, con el hardware del sistema y con
demás software?
 Atributos de Calidad.
 Disponibilidad, tiempo de respuesta, tiempo de recuperación después de fallas, etc.
 Restricciones de diseño. Existen estándares a cumplir, lenguaje de programación, recursos,
sistemas operativos, etc.

Figura 3. Standard IEEE para un SRS.

Lectores de un SRS.
 Clientes y Usuarios (Interesados en validar objetivos del sistema y descripción de alto nivel
de la funcionalidad).
 Analistas (De sistemas, de requerimientos).
 Desarrolladores (Ejemplo: Arquitectos, diseñadores, programadores, etc.).
 Testers.
 Gerentes. [9]

Metodologías Ágiles.
En la metodología XP se recomienda usar la técnica Historias de Usuarios para la recolección de
requerimientos. SCRUM utiliza una lista priorizada de características a implementar denominada
Backlog.

Ciclo de vida de un proyecto en XP.

 Exploración: En esta fase, los clientes plantean a grandes rasgos las historias de usuario
que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en
el proyecto. Se construye un prototipo.

9
Unidad 1. Ingeniería de Requerimientos.

 Planificación de la Entrega (Release): En esta fase el cliente establece la prioridad de cada

historia de usuario, y correspondientemente, los programadores realizan una estimación
del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la
primera entrega y se determina un cronograma en conjunto con el cliente, esta fase dura
unos pocos días.

 Iteraciones: Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El
Plan de Entrega está compuesto por iteraciones de no más de tres semanas. Al final de la
última iteración el sistema estará listo para entrar en producción. Los elementos que
deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de
usuario no abordadas, velocidad del proyecto, pruebas de aceptación no superadas en la
iteración anterior y tareas no terminadas en la iteración anterior

 Producción: La fase de producción requiere de pruebas adicionales y revisiones de

rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo
tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión
actual.

 Mantenimiento: Mientras la primera versión se encuentra en producción, el proyecto XP

debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. La fase de
mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su
estructura.

 Muerte del Proyecto: Es cuando el cliente no tiene más historias para ser incluidas en el
sistema. Se genera la documentación final del sistema y no se realizan más cambios en la
arquitectura. [10]

Figura 4. Fases de un proyecto en XP.

Historias de usuario.
 Las escriben los propios clientes, tal y como ven ellos las necesidades del sistema.
 Las historias de usuario son similares al empleo de escenarios, con la excepción de que no
se limitan a la descripción de la interfaz de usuario.

10
Unidad 1. Ingeniería de Requerimientos.

 También conducirán el proceso de creación de los test de aceptación (empleados para

verificar que las historias de usuario han sido implementadas correctamente).
 Existen diferencias entre estas y la tradicional especificación de requisitos. La principal
diferencia es el nivel de detalle. Las historias de usuario solamente proporcionaran los
detalles sobre la estimación del riesgo y cuánto tiempo conllevará la implementación de
dicha historia de usuario. [10]

Figura 5. Ejemplo de historia de usuario.

SCRUM.
Es un marco de trabajo para agilizar el desarrollo de software y asegurar que el producto se
termine en el tiempo más corto posible. Está compuesto por equipos Multi-funcionales y auto-
administrados encabezados por un Scrum Master que trabajan en ciclos repetitivos de 30 días
conocidos como Sprints.

El trabajo a realizar durante cada una de estas cortas iteraciones es seleccionado por el equipo de
desarrollo de una lista conocida como el "Product Backlog"; este es un simple listado de
requerimientos priorizado por el Dueño del producto en base al valor que cada requerimiento da al
negocio.

Al principio de cada Sprint se lleva a cabo una reunión de planeación ("Sprint Planning Meeting")
donde se analizan los requerimientos más prioritarios y se estima el esfuerzo necesario para
completarlos. De ese Product Backlog el equipo selecciona los requerimientos más prioritarios que
puede desarrollar completamente en 30 días y define y estima las tareas necesarias para cumplir
con esos requerimientos ("Sprint Backlog"). El equipo trabaja sobre esta lista de tareas durante 30
días con el objetivo de tener una pieza funcional de software al final del Sprint. Al final del sprint el
equipo de desarrollo hace una demostración del software que termino al  Dueño del producto, esta
demostración se conoce como "Sprint Review Meeting". Este proceso se repite tantas veces como
sea necesario hasta que el Dueño del producto determina que tiene un producto que puede ser
implementado. [11]

11
Unidad 1. Ingeniería de Requerimientos.

Figura 7. SCRUM, de forma ilustrativa.

Backlog del producto.

 Listado de requerimientos expresados en forma de Historias de Usuario y estimados en
alguna unidad de tiempo.

 Se puede fácilmente llevar y controlar en una hoja electrónica.

 Este listado es priorizado por el dueño del producto de manera permanentemente y

estimado por el equipo en cada reunión de planeación.

 Debe incluir el mayor número de requerimientos que se puedan obtener de los usuarios y
demás interesados del proyecto a través del dueño del producto y en base a las
estimaciones del equipo de programación.

 El Backlog del producto es la herramienta principal para desarrollar y estimar el plan de

liberación del producto.

 El equipo selecciona los requerimientos de más alto nivel que puede completar en 30 días
en base a su capacidad y velocidad de desarrollo y produce el Backlog del sprint. [12]

Figura 8. Ejemplo de Backlog Product.

12
Unidad 1. Ingeniería de Requerimientos.

RFP/ Solicitud de Propuesta.

RFP (Request for Proposal) es un documento que específica el desarrollo de un sistema. Las
propuestas deben formularse en lenguaje claro, terminología integral y formato estandarizado.

Un RFP debe contener:

 Especificación del producto o servicio requerido, con el mayor detalle posible.
 Información que se requiere del oferente, como el valor, las personas que liderarán el
proyecto, un cronograma.
 Criterios para selección o descalificación de proponentes.
 Fechas relevantes, incluyendo las de apertura y cierre del proceso. Fechas para entrevistas
y visitas si las hay.
 Cualquier requerimiento de confidencialidad.
 Elementos legales de la posible contratación.

Figura 9. Ejemplo de plantilla RFP.

Escenarios.
Son descripciones de ejemplos de las sesiones de interacción con el sistema. Inicia con un
bosquejo y durante la obtención de agregan detalles. Un escenario incluye:

 Una descripción del estado del sistema al inicio del escenario.

 Una descripción del flujo normal de eventos en el escenario.
 Una descripción de lo que puede ir mal y cómo manejarlo.
 Información de otras actividades que se podrían llevar al mismo tiempo.
 Una descripción del estado del sistema después de completar el escenario.

Enfoques estructurados: Escenarios de eventos y Casos de uso. [13]

13
Unidad 1. Ingeniería de Requerimientos.

Procesos de la Ingeniería de Requerimientos.

 Requerimientos de Proceso: Describen los requerimientos funcionales y no funcionales de

tal forma que sean comprensibles por los usuarios del sistema. Especifican el
comportamiento externo del sistema y evitan, las características de diseño del sistema.
Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos
sencillos.
 Requerimientos del Usuario: Problemas que se presentan cuando se redacta en lenguaje
natural: Falta de claridad, Confusión de requerimientos, Conjunción de requerimientos.
Los requisitos se agrupan en categorías y se organizan en subconjuntos, se analiza cada
requisito en relación con el resto, se examina los requisitos en su consistencia,
completitud y ambigüedad, y se clasifican en base a las necesidades de los
clientes/usuario.
 Requerimientos para el Análisis y Negociación: Para hacer el Análisis de requisitos se
plantean las siguientes cuestiones: ¿Cada requisito es consistente con los objetivos
generales del sistema/producto?, ¿Tienen todos los requisitos especificados el nivel
adecuado de abstracción?, ¿Algunos requisitos tienen un nivel de detalle técnico
inapropiado en esta etapa?
En el proceso de negociación; los clientes deberán clasificar sus requisitos y discutir los
posibles conflictos según su prioridad, los riesgos asociados con cada requisito serán
identificados y analizados, se efectúan estimaciones del esfuerzo de desarrollo que se
utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de
entrega.
Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando
y/o modificando para conseguir satisfacer los objetivos planteados.
 Requerimientos para la Gestión: La gestión de requerimientos es el proceso de
comprender y controlar los cambios en los requerimientos del sistema y se lleva a cabo
junto con el proceso de ingeniería de requerimientos. [14]

Figura 10. Diagrama que muestra los procesos de la Ingeniería de Requerimientos.

Métricas Técnicas Del Software.

 Se aplica las métricas para valorar la calidad de los productos de ingeniería o los sistemas
que se construyen.
 Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de
reglas claramente definidas.
 Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales.

14
Unidad 1. Ingeniería de Requerimientos.

Calidad del Software.

Figura 11. Factores de calidad McCall y colegas (1997).

Rúbrica.
Una rúbrica es una herramienta de calificación utilizada para realizar evaluaciones subjetivas. Es
un conjunto de criterios y estándares ligados a los objetivos de aprendizaje usados para evaluar la
actuación en la creación de un proyecto. Las características de una rúbrica son:

 Enfocarse en medir un objetivo establecido (desempeño, comportamiento o calidad).

 Usar un rango para el desempeño.
 Contener características específicas del desempeño, ordenadas en niveles, para indicar
qué tanto de un estándar se ha satisfecho. [15]

Figura 12. Ejemplo de Rúbrica.

FURPS+.
Son las siglas que representan un modelo para clasificar cualidades de la calidad del software
(requisitos), el modelo fue desarrollado en HP (Hewlett-Packard).

15
Unidad 1. Ingeniería de Requerimientos.

 Functionality: Sistema de la característica, capacidades, generalidad, seguridad.

 Usability: Factores humanos, estética, consistencia, documentación.
 Reliability: Frecuencia/severidad de la falta, recuperabilidad, previsibilidad, exactitud.
 Performance: Velocidad, eficacia, rendimiento de procesamiento, tiempo de reacción.
 Supportability: Extensibilidad, adaptabilidad, capacidad de mantenimiento,
compatibilidad, flexibilidad de configuración, utilidad, portabilidad.

+ fue agregado más adelante al modelo después de varias campañas, para ampliar las siglas para
acentuar varias cualidades.

Figura 12. Clasificación de Requerimientos con FURPS+.

Prototipos.
El modelo de prototipos debe ser construido en poco tiempo, usando los programas adecuados y
no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros podemos iniciar
el verdadero desarrollo del software.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán
visibles para el cliente o el usuario final, lo cual conduce a la construcción de un prototipo, el cual
es evaluado por el cliente para una retroalimentación.

Ventajas:
 Útil cuando el cliente conoce los objetivos generales para el software, pero no identifica
los requisitos detallados de entrada, procesamiento o salida.
 Ofrece mejor enfoque cuando el responsable del desarrollo del software está inseguro de
la eficacia de un algoritmo o de la adaptabilidad de un sistema operativo.
 Ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el
resultado de la construcción cuando los requisitos estén satisfechos.

Inconvenientes:
 El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema
final.

16
Unidad 1. Ingeniería de Requerimientos.

 A causa de la intención de crear un prototipo de forma rápida, se suelen desatender

aspectos importantes, como la calidad y el mantenimiento a largo plazo.
 En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas
decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de
programación incorrecto porque proporcione un desarrollo más rápido). [16]

Ejemplos de prototipos.
Digamos que eres un ingeniero del equipo de iTunes. Tu primera labor es imaginar cómo será la
interfaz para poder desarrollar sus características alrededor de ella. Mediante modelo de
prototipos se logra esto:

Figura 13. Ejemplo de Prototipo para el software iTunes creado con Balsamiq Mockups.

JAD (Joint Application Development).

En español Desarrollo Conjunto de Aplicaciones, es una técnica exploratoria que incluye a los
usuarios como participantes activos en el proceso de desarrollo. El proceso de JAD se basa en
cuatro ideas simples:

 La gente que hace un trabajo tiene la mejor comprensión de ese trabajo.

 La gente entrenada en Tecnologías de la Información tiene la mejor comprensión de las
posibilidades de esas tecnologías.
 Los sistemas de información y los procesos del negocio raramente existen en forma
aislada.
 Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan
juntos en un proyecto como socios iguales.

Ventajas: Permite que los usuarios participen más efectivamente en los procesos, les da una
sensación de pertenencia con respecto al sistema, cumple con mayor precisión los requerimientos
del sistema y mejor entendimiento de las metas comunes.

17
Unidad 1. Ingeniería de Requerimientos.

Desventajas: Comparado con los métodos tradicionales suele ser más caro, y si el grupo es muy
grande el costo aumenta significativamente. [17]

VORD.
El método VORD (Definición de Requerimientos Orientada a Puntos de Vista) admite un enfoque
orientado a servicios que es conveniente para los sistemas interactivos. Este método se basa en el
análisis de puntos de vista externos que interactúan con el sistema mediante la recepción de los
servicios y dando datos al sistema. VORD contiene las siguientes etapas:

 Identificación (Quienes reciben qué servicios).

 Estructuración (Jerarquía).
 Documentación (Refinación).
 Trazado (Conversión a diseño Orientado a Objetos). [18]

Etnografía.

Análisis Etnográfico:
 Un científico social pasa un tiempo considerable observando y analizando cómo trabaja la
gente.
 Las personas no tienen que explicar o articular su trabajo.
 Los factores sociales y organizacionales de importancia deben ser observados.
 Estudios etnográficos han mostrado que el trabajo usualmente es más abundante y más
complejo que lo sugerido por los modelos de sistemas sencillos.

Enfoque Etnográfico:
 Desarrollado en un proyecto de estudio del proceso de control de tráfico aéreo.
 Combina tecnología con prototipado.
 El desarrollo de un prototipo trasciende en preguntas sin respuesta lo cual enfoca el
análisis etnográfico.
 El problema con la etnografía es que estudia las prácticas existentes, las cuales pueden
tener alguna base histórica que ya no es relevante.

Desarrollo de la etnografía:
 El uso de la etnografía en el análisis de requerimientos necesita ser desarrollado tal que
pueda ser combinado con métodos más sistemáticos.
 Conforme la importancia de los factores humanos, sociales y organizacionales se vuelven
más ampliamente reconocidos. [19]

Diccionario de datos.
Contiene las características lógicas de los datos que se van a utilizar en el sistema que estamos
programando, incluyendo nombre, descripción, alías, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que
participan en la determinación de los requerimientos del sistema, su contenido también se emplea
durante el diseño del proyecto.

18
Unidad 1. Ingeniería de Requerimientos.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo
de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de
datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos
elementos. [20]

Conclusión.
La evolución de los estudios encarados por la Ingeniería de Requerimientos se fue dando
paulatinamente. Sin embargo, a partir de los 90, los esfuerzos se concentraron en la búsqueda de
técnicas, métodos y herramientas que pudieran ser aplicados durante el proceso de definición de
requerimientos para arribar a una etapa de diseño exitosa.

Es muy importante mencionar que el poder formular una especificación de requerimientos

completa y consistente, es un paso muy importante para evitar cometer errores en la definición de
los requerimientos, ya que los mismos pueden resultar muy caros de corregir una vez desarrollado
el sistema. La importancia que tiene la ingeniería de requerimientos en generar una adecuada
especificación que contemple claramente y sin ambigüedades los requerimientos del sistema a
desarrollar, con el fin primordial de evitar que los proyectos fracasen debido a una mala
elaboración de la definición y especificación de requerimientos.

El proceso de la Ingeniería de Requerimientos sirve para recopilar la información necesaria para

establecer la funcionalidad que se quiere alcanzar con el sistema. Para ello, se debe de contar con
buenas técnicas, además de una comunicación fluida y constante con el cliente, ya que los
requerimientos deben reflejar las necesidades reales que el cliente quiere satisfacer.

La Ingeniería de Requerimientos ayuda a diseñar correctamente en menos tiempo, ayuda a

facilitar la documentación y la comunicación con otros miembros del equipo de desarrollo,
ventajas importantes que se deben de tomar en cuenta por parte los desarrolladores de software,
ya que si se logra tener un lenguaje en común dentro del grupo de trabajo, se reduce el impacto
de los riesgos al utilizar soluciones y amplía el conocimiento de los participantes del desarrollo,
permitiéndoles representar mejores sistemas de una manera más estructurada.

19
Unidad 1. Ingeniería de Requerimientos.

Referencias.

[1] "Competencias". Disponible en http://www.rrppnet.com.ar/competencias.htm

[2] [Standish 1998] Standish Group. The Chaos Report. Disponible en

http://www.standishgroup.com/sample_research/PDFpages/chaos1998

[3] McManus, John y Wood-Harper, Trevor (2003) "Information systems project management: The
price of failure", pp. 16-19. Disponible en:
http://proquest.umi.com/pqdweb?
index=10&did=000000346162901&SrchMode=1&sid=2&Fmt=6&VInst=PROD&VType=PQD&RQT=
309&VName=PQD&TS=1067570441&clientId=39522

[4] "Ingeniería de Software". Disponible en

http://www.monografias.com/trabajos5/inso/inso.shtml

[5] "Requerimiento (sistemas)". Disponible en

http://es.wikipedia.org/wiki/Requerimiento_(sistemas)

[6] "Ingeniería de Requerimientos". Disponible en

http://www.monografias.com/trabajos6/resof/resof.shtml

[7] "Proceso de la Ingeniería de Requerimientos". Disponible en

http://danielvn7.wordpress.com/2008/03/27/proceso-de-la-ingenieria-de-requisitos/

[8] Michael Arias Chaves "La ingeniería de requerimientos y su importancia en el desarrollo de

proyectos de software". Disponible en
http://www.latindex.ucr.ac.cr/intersedes10/10-art_11.pdf

[9] "El Documento de Requerimientos", pp. 1-3.

[10] "Ciclo de vida de un proyecto XP". Disponible en

http://oness.sourceforge.net/proyecto/html/ch05s02.html

[11] "SCRUM en pocas palabras". Disponible en

http://scrumenespanol.blogspot.com/2007/12/scrum-en-pocas-palabras.html

[12] "SCRUM en muchas palabras". Disponible en

http://scrumenespanol.blogspot.com/2007/12/scrum-en-muchas-palabras.html

[13] "Escenarios". Disponible en

http://www.mena.com.mx/gonzalo/maestria/ingreq/presenta/procesos_ir/

20
Unidad 1. Ingeniería de Requerimientos.

[14] "Unidad 1, Requerimientos". Disponible en

http://www.slideshare.net/guest409adc/unidad-i-requerimientos-presentation

[15] "Rúbrica". Disponible en http://es.wikipedia.org/wiki/Rúbrica

[16] "Modelo de Prototipos". Disponible en http://es.wikipedia.org/wiki/Modelo_de_prototipos

[17] "Joint Application Development”. Disponible en

http://es.wikipedia.org/wiki/Joint_application_development

[18] "Requirement analysis using VORD". Disponible en

http://ieeexplore.ieee.org/iel5/7318/19790/00915849.pdf

[19] "Análisis Requerimientos". Disponible en http://www.slideshare.net/jlchipana/analisis-

requerimientos

[20] "Diccionario de datos". Disponible en

http://www.mitecnologico.com/Main/DiccionarioDeDatos

21