SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

SEMANA 6

Gestión de requerimientos

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
IACC-2019
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni
utilizar los contenidos para fines comerciales de ninguna clase. 1
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

1.

APRENDIZAJE ESPERADO
 Estructurar requerimientos para un
proyecto de software, aplicando técnicas
y buenas prácticas.

IACC-2019
2
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

OBJETIVOS ESPECÍFICOS ................................................................................................................. 2

INTRODUCCIÓN ............................................................................................................................. 4
1. Gestión de requerimientos ..................................................................................................... 5
1.1. Actividades de Gestión de Requerimientos ................................................................. 5
1.2. Gestión del alcance de la Solución/Requerimientos .................................................... 7
1.3. Gestión de la trazabilidad de Requerimientos ............................................................. 7
1.4. Preparación de Paquetes de Requerimientos .............................................................. 8
1.5. Priorización de Requerimientos .................................................................................. 9
1.6. MoSCoW/ Timeboxing / Presupuesto / Grado ........................................................... 10
1.7. Mejores prácticas para escritura de requerimientos ................................................. 11
COMENTARIO FINAL .................................................................................................................... 12

IACC-2019
3
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

INTRODUCCIÓN
Como se ha estudiando en a lo largo de esta estructurado el paso a paso de la realización
asignatura, la gestión de requerimeintos logra del proyecto, siempre teniendo en cuenta los
establecer lo que los sistemas deben hacer en requerimientos de software y los
cuanto a sus tareas, restrinciones y cualquier requerimientos de sistemas. Los primeros se
solicitud realizada por la organización, para originan en los requerimientos y
así poder lograr y alcanzar los propositos especificaciones de sistema, mientras que los
reales de proyecto. segundos radican en las necesidades del
usuario.
En relación a esto, se presentan una serie de
actividades que van a definir cómo será

"Hoy en día la mayoría del software existe no para resolver un problema, sino para actuar de
interfaz con otro software”
I. O. Angell

IACC-2019
4
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

1. GESTIÓN DE REQUERIMIENTOS
1.1. ACTIVIDADES DE GESTIÓN DE REQUERIMIENTOS
Las actividades fundamentales que abarcan la gestión de requerimientos según Báez (2019), son
tres:

 Generación de requerimientos

Esta primera actividad tiene la habilidad de entender las necesidades de los interesados, y
recopilarlos en un repositorio para futuros análisis. Estas necesidades pueden ser expresadas de
forma abstracta y en términos de problemas o bien concretos y en términos de una solución. En
ambos casos las necesidades son conocidas como características.

 Evaluación de requerimientos

Como segunda actividad se presenta la evaluación de requerimientos, esta es la habilidad de

discernir qué características son apropiadas para incluir en el producto, dado que raramente es
posible satisfacer todas las características demandadas por cada uno de los interesados. La
evaluación tiene en consideración todas las realidades del mercado y toma la decisión acerca de
qué características se implementará, cuales lo serán en la próxima versión, y cuales se aplazarán
hasta más tarde.

 Especificación de requerimientos

Por último pero no menos importante se explica la especificación de requerimientos como la

habilidad de detallar el comportamiento de un sistema. En cada parte del proceso de desarrollo,
variaran la forma y el nivel de detalle en la especificación de los requerimientos. Para ilustrarlo,
considérese un proceso estándar de desarrollo en 5 fases: investigación, viabilidad, diseño,
construcción y test, lanzamiento, dichas fases se describen a continuación:

o Investigación

En esta fase, se recopilan requerimientos entre los usuarios y los miembros del equipo de desarrollo.
Para cada uno de ellos se formulan cuestiones similares acerca de cuáles son los logros, las
restricciones y las herramientas o procesos disponibles, solo cuando estos requerimientos sean bien
entendidos, se pueden desarrollar los requerimientos funcionales.

Se debe tener muy presente que los requerimientos no pueden ser completamente definidos al
inicio del proyecto. Algunos cambiarán, bien porque sean simplemente suprimidos, o debido a los
intereses y modificaciones que afecten al ciclo de vida del proyecto.

IACC-2019
5
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

Por ello, la flexibilidad en los planteamientos y las operaciones, son condiciones para el éxito.

Mientras que muchas organizaciones todavía utilizan solo documentos para gestionar los
requerimientos, otras gestionan a partir de herramientas de software. Estas herramientas permiten
gestionar los requerimientos en una base de datos y acostumbran a tener funciones para
automatizar la trazabilidad, como por ejemplo permitir la vinculación electrónica entre la jerarquía
de requerimientos, el control de versiones y la gestión de cambios.

o Viabilidad

Durante el estudio de viabilidad, se determinan:

 Los costes de los requerimientos: para los requerimientos de usuario, se comparan los
costes actuales con los futuros, una vez se haya implementado el nuevo sistema.
 Los costes de operación: indicarán qué departamento tiene presupuesto para ello y cuál es
el retorno de inversión para este producto, incluyendo la reducción de costes si se desarrolla
un nuevo sistema más fácil de utilizar.
 Los costes técnicos: están relacionados con los costes de desarrollo de software y los costes
del hardware. El equipo debe indagar si los nuevos equipos y herramientas añadirán
suficiente potencia de procesamiento para transferir suficiente carga de trabajo del usuario
al sistema que permita un ahorro significativo de tiempo y costes al personal.
 El entregable para el estadio de estudio de viabilidad son la programación y el presupuesto
para el proyecto.

o Diseño

Asumiendo que los costos han sido determinados con precisión y que los beneficios a obtener son
suficientemente importantes, el proyecto puede pasar al estadio de diseño. En dicho estadio, la
actividad principal de la gestión de requerimientos es comparar los resultados del diseño con el
documento de requerimientos, para asegurarse de que el trabajo está contemplado dentro del
alcance.

o Implementación y test

En la implementación y test, la actividad principal de la gestión de requerimientos, es asegurar que

el trabajo y el coste se desarrollan de acuerdo con la programación y el presupuesto, y que las
nuevas herramientas cumplen de hecho con los requerimientos. La herramienta principal utilizada
en este estadio es la construcción de prototipos y el test iterativo. Para una aplicación de software,
la interfaz de usuario puede ser creada en papel y probada con los usuarios potenciales, mientras
está siendo creado el entorno de software. Los resultados de dichos test son archivados en una guía

IACC-2019
6
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

de diseño de interfaz de usuario y trasladado al equipo de diseño, cuando este esté listos para
desarrollar la interface. Esto ahorra tiempo y hace el trabajo mucho más fácil.

o Lanzamiento

Podría pensarse que la gestión de requerimientos finaliza al entregar el producto, pero no es del
todo cierto. Desde este punto, se recopilan los datos provenientes de la aceptación de la aplicación,
y utilizados posteriormente en la fase de investigación de la nueva generación o versión. Entonces,
el proceso empieza de nuevo.

1.2. GESTIÓN DEL ALCANCE DE LA

SOLUCIÓN/REQUERIMIENTOS
En este particular, Angulo (2014), explica que el plan de gestión del alcance es uno de los planes
subsidiarios más importantes contenidos en el plan de dirección de proyecto. Este describe su
proceso particular para definir de forma iterativa el detalle del alcance del proyecto y del producto;
el proceso de descomposición para la creación de la estructura de desglose del trabajo (un proceso
que utiliza el enunciado del alcance que sea ha desarrollado para ejecutar el trabajo del proyecto)
el proceso por el cual las solicitudes de cambio serán consideradas para ser aprobadas o rechazadas.
Además de estos elementos, también se presentan el proceso de validar el alcance y los entregables
del proyecto, y como se obtendrá el visto bueno para el cierre. Una vez más, el detalle del plan de
gestión del alcance reflejará el detalle del alcance del proyecto. Un alcance muy definido se traducirá
en un plan de gestión del alcance, y un alcance vagamente definido se traducirá en un plan de
gestión del alcance más flexible, permitiendo más iteraciones.

1.3. GESTIÓN DE LA TRAZABILIDAD DE REQUERIMIENTOS

Según Sevilla (2016), la trazabilidad de requisitos es la asociación de un requisito con otros requisitos y
las diferentes instancias o artefactos con que se relaciona, así como la habilidad de describir y seguir el
ciclo de vida completo de un requisito, desde su origen, pasando por su desarrollo y especificación y
finalizando con su despliegue.

Es importante identificar y establecer el nivel de detalle que se requiere hacia los diferentes casos
de uso, reglas de negocio, características y atributos. Es necesario seleccionar aquellas asociaciones
que son de interés relevante para el análisis, para su posterior análisis ante un posible cambio en

IACC-2019
7
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

los elementos que se puedan ver afectados. Debido a esto, resulta fundamental que la trazabilidad
siempre esté actualizada y refleje la realidad del proyecto en tiempo real.

Disponer de una buena trazabilidad de requisitos nos permite realizar el control y apoyo para la
toma de decisiones en el proyecto. Por ejemplo, una de las ventajas principales que ofrece la
trazabilidad es poder determinar si todos los requisitos han sido considerados y si las instancias que
han sido generadas pueden asociarse con un requisito válido.

Gracias a la trazabilidad de requisitos se tiene la posibilidad de identificar el origen de cada requisito

y realizar el seguimiento de cada cambio que se realice sobre el mismo. Además, al trazar los
requisitos con otros artefactos como pruebas, casos de uso, código, etc., será posible responder a
los cambios de forma más controlada y con más información, y en consecuencia anticiparnos a lo
que un cambio puede significar.

Una de las técnicas más utilizadas para recoger la información bidireccional de trazas, son las
matrices de trazabilidad. Estas muestran diversos elementos en filas y columnas (por ejemplo,
requisitos y pruebas) indicando en cada celda de la matriz si los elementos están o no trazados y en
qué dirección. Este tipo de técnicas permite un análisis gráfico de la trazabilidad de requisitos y la
gestión de su impacto ante posibles cambios.

1.4. PREPARACIÓN DE PAQUETES DE REQUERIMIENTOS

Para Pressman (2010), la preparación de paquetes de requerimientos es la que combina elementos
de la solución de problemas, elaboración, negociación y especificación. A fin de estimular un
enfoque colaborativo y orientado al equipo, los participantes trabajan juntos para identificar el
problema, proponer elementos de la solución, negociar distintas visiones y especificar un conjunto
preliminar de requerimientos para la solución.

Se han propuesto muchos enfoques distintos para recabar y preparar los requerimientos en forma
colaborativa. Cada uno utiliza un escenario un poco diferente, pero todos son variantes de los
siguientes lineamientos básicos:

• Tantos ingenieros de software como otros participantes dirigen o intervienen en las reuniones.

• Se establecen reglas para la preparación y participación.

• Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero
con la suficiente informalidad para que estimule el libre flujo de ideas.

• Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión.

IACC-2019
8
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

• Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas, etiquetas
adhesivas, pizarrón electrónico, grupos de conversación o foro virtual).

La meta es identificar el problema, proponer elementos de la solución, negociar distintos enfoques

y especificar un conjunto preliminar de requerimientos de la solución en una atmósfera que
favorezca el logro de la meta. Para entender mejor el flujo de eventos conforme ocurren, se
presenta un escenario breve que bosqueja la secuencia de hechos que llevan a la reunión para
obtener requerimientos, a lo que sucede durante esta y a lo que sigue después de ella.

1.5. PRIORIZACIÓN DE REQUERIMIENTOS

Según Fernández (2006), después de identificar los requerimientos, el analista debe priorizarlos, ya
que no todos los requerimientos son igualmente importantes para la organización, por ello existen
varios métodos para priorizar los requerimientos, como son los basados en versiones, sin embargo,
todos se basan en premisas.

Para comenzar, el analista de sistema debe diferenciar entre tres tipos de requerimientos:

 Requerimientos esenciales para la organización. En este grupo el analista de sistema debe

incluir todos los requerimientos que deben estar obligatoriamente en el sistema desde el
punto de vista de las necesidades de la organización. Los requerimientos esenciales no
pueden priorizarse ni ordenarse, ya que todos son necesarios (obligatorios) para el correcto
funcionamiento del sistema.
 Requerimientos deseables para la organización. Las necesidades de este tipo no son
esenciales para el funcionamiento de la organización, sin embargo, su implementación
proporcionaría a la organización ventajas muy deseables. En este caso, los requerimientos
sí que pueden ser priorizados en función del beneficio que puedan aportar a la organización.
 Requerimientos opcionales. Engloban el resto de las necesidades de los usuarios y de la
organización. Los requerimientos opciones pueden beneficiar en cierta medida a una parte
de los usuarios, o solo a uno; sin embargo, su no implementación afecta de forma muy leve
al funcionamiento y al rendimiento de la organización. Al igual que antes, los
requerimientos opcionales también pueden ser priorizados.

Un método para diferenciar los requerimientos esenciales del resto de requerimientos es intentar
ordenarlos por importancia. Aquellos que no puedan ser ordenados o priorizados son
requerimientos esenciales, y los que permitan ser priorizados son requerimientos deseables o bien
requerimientos opcionales.

IACC-2019
9
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

La priorización de los requerimientos es un trabajo que afecta básicamente a los propietarios y a los
usuarios del sistema, bajo la supervisión del analista del sistema. Aunque en la literatura existen
varios métodos para priorizar requerimientos, la realidad muestra que una buena clasificación y
priorización se presenta en la mayoría de las ocasiones de la experiencia.

Una vez priorizados y categorizados los requisitos, es recomendable utilizar herramientas de gestión
de requisitos que nos faciliten la comprobación del cumplimiento de dichos requisitos.

1.6. MOSCOW/ TIMEBOXING / PRESUPUESTO / GRADO

Sevilla (2016), una de las técnicas más utilizadas en la priorización de requisitos es la conocida como
técnica MoSCoW. Se trata de una técnica de priorización de requisitos basada en el hecho de que,
aunque todos los requisitos se consideren importantes, es fundamental destacar aquellos requisitos
vitales que aportan un mayor valor al negocio y que son considerados obligatorios, de forma que el
producto o servicio no se puede poner en producción si incumple alguno de estos requisitos. Esto
nos ayudará a enfocar el desarrollo de forma más eficiente.

La técnica MoSCoW no se limita a indicar si un requisito es de prioridad baja, media o alta. Esta
técnica ayuda a separar los requisitos en cuatro grandes categorías:

 M – Must: requisitos fundamentales y obligatorios para satisfacer las necesidades del negocio.
Si estos no se cumplen, se verá comprometido el éxito del servicio.
 S – Should: requisitos que deberían ser cumplidos en la medida de lo posible. El éxito del
proyecto o servicio no dependerá directamente del cumplimiento de estos requisitos. Estos
requisitos pueden ser satisfechos mediante soluciones temporales, o llegado el momento si
fuera necesaria, podrían ser prescindibles si existiera alguna causa que lo justificara.
 C – Could: requisitos que son interesantes que cumpla el servicio. Se trata de requisitos
adicionales que se implementarán en el caso de disponer de tiempo y presupuesto para ello.
Estos requisitos mejorarían el rendimiento del servicio, pero podrían ser eliminados fácilmente.
 W – Won’t: requisitos que se ha decidido no implementar de momento, pero que serán tomados
en cuenta en el futuro con el objetivo de mejorar el servicio o producto.

Esta categorización ayuda a marcar una “línea roja”, identificando aquellos requisitos que
obligatoriamente deben ser incluidos en el desarrollo del servicio. Es muy fácil de entender por
todas las partes interesadas, y de poner en práctica, ya que se define claramente cuáles son los
requisitos básicos sin los cuales no se pondrá en producción el servicio.

El Timeboxing hace referencia a una técnica ágil empleada para gestionar el desempeño del trabajo
y el alcance. Básicamente consiste en establecer una duración máxima de tiempo: tanto de inicio

IACC-2019
10
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

como de fin. Durante dicho tiempo, una iteración o sprint en scrum, se espera que el equipo de
desarrollo, manteniendo un ritmo constante, sea capaz de desarrollar un conjunto de
funcionalidades previamente establecidas.

1.7. MEJORES PRÁCTICAS PARA ESCRITURA DE

REQUERIMIENTOS
A continuación, se muestran una serie de mejores prácticas relacionadas con la gestión de
requisitos:

 Priorizar requisitos: para determinar aquellos que se deberían cumplir en la primera versión
o producto y aquellos que pueden llevarse a cabo en sucesivas versiones.
 Establecer líneas base de los requisitos: para asegurar que cualquier modificación en los
requisitos que cambie la línea base se trata como cambios de alcance.
 Comunicación abierta: para asegurar que la información relacionada con los requisitos se
comunica de forma consistente. Una comunicación abierta también implica comunicar a la
gente correcta y al conjunto mínimo de personas
 Gestión de cambios de los requisitos: es esencial gestionar estos cambios de forma efectiva
y eficiente.
 Uso de herramientas para la gestión de requisitos: para facilitar la gestión de requisitos
 Mantener trazabilidad de requisitos: para llevar un seguimiento de la vida de un requisito
 Establecer un plan de mejora de procesos para la ingeniería de requisitos: para cumplir
con las necesidades actuales y futuras de forma más eficiente y con mayor calidad.
 Formar a los analistas de requisitos: para asegurar que los analistas de requisitos tengan el
conocimiento, entre otros aspectos, de cómo escribir buenos requisitos.

IACC-2019
11
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

COMENTARIO FINAL
Al tener claras las actividades a realizar la gestión de requerimientos, es mucho más fácil para el
ingeniero de software, debido a que ya todas las tareas están bien definidas para su próxima
ejecución. Esto hace que la calidad del producto mejore dentro de lo posible y que se puedan
gestionar las peticiones de algún cambio en las especificaciones de los requisitos. Junto a esto se
debe considerar la trazabilidad de los requisitos en la gestión de proyecto.

Se debe acotar que la gestión de requerimientos puede cambiar en la medida de los avances del
proyecto y sus actividades podrán sufrir alguna variante. Esto no implica que el trabajo realizado
esté errado, solo que mediante las necesidades que vayan surgiendo, se debe ir adaptando el
proceso para lograr una buena elaboración del sistema.

IACC-2019
12
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

REFERENCIAS
Fernández, V. (2006). Desarrollo de sistemas de información. Barcelona: Ediciones UPC

Báez, J. (2009). Gestión de requerimientos V: actividades. Barcelona:

http://blog.masterinprojectmanagement.net/gestion-de-requerimientos-v-actividades/

Pressman, R. (2010). Ingeniería del software. Un enfoque práctico. 7.ª edición. México:MC Graw

Hill

Sevilla, J(2016). Priorización de requisitos - Técnica MoSCoW. Peru: http://www.overti.es

/tecnologia/275-priorizacion-de-requisitos-tecnica-moscow

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2019). Análisis de requerimiento. Ingeniería en Requerimiento de Software. Semana 6.

IACC-2019
13
SEMANA 6 – INGENIERÍA EN REQUERIMIENTO DE SOFTWARE

IACC-2019
14