Contenido

1.2.1 Obtención de requerimientos...................................................................................................2

1.2.1.1 Técnicas y herramientas de obtención de requerimientos................................................3
1.2.1.1.1 Entrevistas...................................................................................................................3
1.2.1.1.2 Recabación de los requerimientos en forma colaborativa..........................................3
1.2.1.1.3 Escenarios....................................................................................................................4
1.2.1.1.4 Casos de uso................................................................................................................5
1.2.1.1.5 Etnografía....................................................................................................................5
1.2.1.1.6 Despliegue de la función de calidad............................................................................6
1.2.2 Análisis de requerimientos........................................................................................................7
1.2.2.1 Proceso de análisis de requerimientos...............................................................................7
1.2.2.2 Técnicas y herramientas de análisis de requerimientos.....................................................9
1.2.2.2.1 Defina los requisitos con precisión..............................................................................9
1.2.2.2.2 Priorizar requisitos......................................................................................................9
1.2.2.2.3 Realizar un análisis de impacto....................................................................................9
1.2.2.2.4 Resolver conflictos.......................................................................................................9
1.2.2.2.5 Analizar viabilidad.......................................................................................................9
1.2.3 Priorización de requerimientos.................................................................................................9
Conocimiento del participante sobre un requerimiento..........................................................10
Categorización del individuo....................................................................................................10
Valor asignado..........................................................................................................................10
1.2.3.1 Técnicas y herramientas de priorización de requerimientos............................................11
1.2.3.1.1 Dentro o fuera...........................................................................................................11
1.2.3.1.2 Comparación por pares y ordenación de rangos.......................................................11
1.2.3.1.3 Escala de tres niveles.................................................................................................11
1.2.4 Validación de requerimientos.................................................................................................12
1.2.4.1 Técnicas y herramientas de validación de requerimientos...............................................13
1.2.4.1.1 Revisiones de requerimientos...................................................................................13
1.2.4.1.2 Creación de prototipos..............................................................................................13
1.2.4.1.3 Generación de casos de prueba................................................................................13
 Análisis de sistemas de Software
1.2 Técnicas y herramientas para obtención, análisis,
priorización y validación de requerimientos
1.2.1 Obtención de requerimientos
El descubrimiento de requerimientos (llamado a veces adquisición de
requerimientos) es el proceso de recopilar información sobre el sistema requerido
y los sistemas existentes, así como de separar, a partir de esta información, los
requerimientos del usuario y del sistema. Las fuentes de información durante la
fase de descubrimiento de requerimientos incluyen documentación, participantes
del sistema y especificaciones de sistemas similares. La interacción con los
participantes es a través de entrevistas y observaciones, y pueden usarse
escenarios y prototipos para ayudar a los participantes a entender cómo será el
sistema.
Los participantes varían desde administradores y usuarios finales de un sistema
hasta participantes externos como los reguladores, quienes certifican la
aceptabilidad del sistema.
Además de los participantes del sistema, se observa que los requerimientos
también pueden venir del dominio de aplicación y de otros sistemas que
interactúan con el sistema a especificar. Todos ellos deben considerarse durante
el proceso de adquisición de requerimientos.
Todas estas diferentes fuentes de requerimientos (participantes, dominio,
sistemas) se representan como puntos de vista del sistema, y cada visión muestra
un subconjunto de los requerimientos para el sistema. Diferentes puntos de vista
de un problema enfocan el problema de diferentes formas. Sin embargo, sus
perspectivas no son totalmente independientes, sino que por lo general se
traslapan, de manera que tienen requerimientos comunes. Usted puede usar estos
puntos de vista para estructurar tanto el descubrimiento como la documentación
de los requerimientos del sistema.

1.2.1.1 Técnicas y herramientas de obtención de requerimientos

Recuerda cada una de las técnicas y herramientas de aquí abajo y obviamente un poco de que va
cada una de ellas, aunque son muy obvias, una entrevista pues es una serie de preguntas, etc.
 T é cn ica s y h e rra m e in ta s
Entrevistas

Recabación de los requerimientos

Escenarios

Casos de uso

Etnografía

Despliegue de la función de calidad

1.2.1.1.1 Entrevistas
Las entrevistas formales o informales con participantes del sistema son una parte
de la mayoría de los procesos de ingeniería de requerimientos. En estas
entrevistas, el equipo de ingeniería de requerimientos formula preguntas a los
participantes sobre el sistema que actualmente usan y el sistema que se va a
desarrollar. Los requerimientos se derivan de las respuestas a dichas preguntas.
Las entrevistas son de dos tipos:
1. Entrevistas cerradas, donde los participantes responden a un conjunto de
preguntas preestablecidas.
2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de
ingeniería de requerimientos explora un rango de conflictos con los
participantes del sistema y, como resultado, desarrolla una mejor
comprensión de sus necesidades.

1.2.1.1.2 Recabación de los requerimientos en forma colaborativa

Se han propuesto muchos enfoques distintos para recabar los requerimientos en
forma colaborativa. Cada uno utiliza un escenario un poco diferente, pero todos
son variantes de los siguientes lineamientos básicos:
• Tanto 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.
• 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 ésta y a lo que sigue después de ella.
Durante la concepción (véase la sección 5.2, Ingeniería de Software, Pressman),
hay preguntas y respuestas básicas que establecen el alcance del problema y la
percepción general de lo que constituye una solución. Fuera de estas reuniones
iniciales, el desarrollador y los clientes escriben una o dos páginas de “solicitud de
producto”:
1. Se selecciona un lugar, fecha y hora para la reunión.
2. Se escoge un facilitador y se invita a asistir a integrantes del equipo de
software y de otras organizaciones participantes.
3. Antes de la fecha de la reunión, se distribuye la solicitud de producto a
todos los asistentes.

1.2.1.1.3 Escenarios
A medida que se reúnen los requerimientos, comienza a materializarse la visión
general de funciones y características del sistema. Sin embargo, es difícil avanzar
hacia actividades más técnicas de la ingeniería de software hasta no entender
cómo emplearán los usuarios finales dichas funciones y características. Para
lograr esto, los desarrolladores y usuarios crean un conjunto de escenarios que
identifican la naturaleza de los usos para el sistema que se va a construir.
Los escenarios son particularmente útiles para detallar un bosquejo de descripción
de requerimientos. Se trata de ejemplos sobre descripciones de sesiones de
interacción. Cada escenario abarca comúnmente una interacción o un número
pequeño de interacciones posibles. Se desarrollan diferentes formas de
escenarios y se ofrecen varios tipos de información con diversos niveles de detalle
acerca del sistema.
Un escenario comienza con un bosquejo de la interacción. Durante el proceso de
adquisición, se suman detalles a éste para crear una representación completa de
dicha interacción. En su forma más general, un escenario puede incluir:
1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el
escenario.
2. Una descripción en el escenario del flujo normal de los eventos.
3. Una descripción de qué puede salir mal y cómo se manejaría.
4. Información de otras actividades que estén en marcha al mismo tiempo.
5. Una descripción del estado del sistema cuando termina el escenario.
1.2.1.1.4 Casos de uso
Los casos de uso son una técnica de descubrimiento de requerimientos que se
introdujo por primera vez en el método Objectory (Jacobson et al., 1993).

Los casos de uso se documentan con el empleo de un diagrama de caso de uso

de alto nivel. El conjunto de casos de uso representa todas las interacciones
posibles que se describirán en los requerimientos del sistema.
Los casos de uso identifican las interacciones individuales entre el sistema y sus
usuarios u otros sistemas. Cada caso de uso debe documentarse con una
descripción textual. Entonces pueden vincularse con otros modelos en el UML
que desarrollará el escenario con más detalle.
Recuerdo que venia sobre UML, sobre qué tipo de modelo utilizar en ciertos
ejemplos prácticos, entonces estaría bien que estudies los modelos más usados
de UML, si los veo en otro archivo pues ahí los marco

1.2.1.1.5 Etnografía
La etnografía es una técnica de observación que se usa para entender los
procesos operacionales y ayudar a derivar requerimientos de apoyo para dichos
procesos. Un analista se adentra en el ambiente laboral donde se usará el
sistema. Observa el trabajo diario y toma notas acerca de las tareas existentes en
que intervienen los participantes. El valor de la etnografía es que ayuda a
descubrir requerimientos implícitos del sistema que reflejan las formas actuales en
que trabaja la gente, en vez de los procesos formales definidos por la
organización.
La etnografía es muy efectiva para descubrir dos tipos de requerimientos:

1. Requerimientos que se derivan de la forma en que realmente trabaja la

gente, en vez de la forma en la cual las definiciones del proceso indican que
debería trabajar.
2. Requerimientos que se derivan de la cooperación y el conocimiento de las
actividades de otras personas.

1.2.1.1.6 Despliegue de la función de calidad

El despliegue de la función de calidad (DFC) es una técnica de administración de
la calidad que traduce las necesidades del cliente en requerimientos técnicos para
el software. El DFC se concentra en maximizar la satisfacción del cliente a partir
del proceso de ingeniería del software. Para lograr esto, el DFC pone el énfasis en
entender lo que resulta valioso para el cliente y luego despliega dichos valores en
todo el proceso de ingeniería. El DFC identifica tres tipos de requerimientos:
o Requerimientos normales. Objetivos y metas que se establecen para un
producto o sistema durante las reuniones con el cliente. Si estos
requerimientos están presentes, el cliente queda satisfecho.
o Requerimientos esperados. Están implícitos en el producto o sistema y
quizá sean tan importantes que el cliente no los mencione de manera
explícita. Su ausencia causará mucha insatisfacción.
o Requerimientos emocionantes. Estas características van más allá de las
expectativas del cliente y son muy satisfactorias si están presentes.
Aunque los conceptos del DFC son aplicables en todo el proceso del software, hay
técnicas específicas de aquél que pueden aplicarse a la actividad de indagación
de los requerimientos. El DFC utiliza entrevistas con los clientes, observación,
encuestas y estudio de datos históricos como materia prima para la actividad de
recabación de los requerimientos. Después, estos datos se llevan a una tabla de
requerimientos —llamada tabla de la voz del cliente— que se revisa con el cliente
y con otros participantes. Luego se emplean varios diagramas, matrices y métodos
de evaluación para extraer los requerimientos esperados y tratar de percibir
requerimientos emocionantes.
1.2.2 Análisis de requerimientos
El análisis de requerimientos es el proceso de definir las expectativas de los
usuarios para una aplicación que se va a construir o modificar. Implica todas las
tareas que se realizan para identificar las necesidades de los diferentes
stakeholders. Recuerdo que venían mucho esa palabra, así que hay que recordar
que un stakeholder es una persona que está implicada/interesada en el desarrollo,
como un inversor, un empleado, un directivo y el mismo dueño. Por lo tanto, el
análisis de requerimientos significa analizar, documentar, validar y gestionar los
requisitos de software o sistema.
Los requerimientos de alta calidad están documentados, procesables, medibles,
comprobables, rastreables, ayudan a identificar oportunidades comerciales y se
definen para facilitar el diseño del sistema.
El análisis de los requerimientos permite al profesional (sin importar si se llama
ingeniero de software, analista o modelista) construir sobre los requerimientos
básicos establecidos durante las tareas de concepción, indagación y negociación,
que son parte de la ingeniería de los requerimientos.
El análisis de requerimientos es un esfuerzo de equipo que exige una combinación
de experiencia en ingeniería de factores humanos, software y hardware, así como
habilidades para tratar con personas. Estas son las principales actividades
involucradas en el análisis de requisitos:
• Identificar las necesidades del cliente.
• Evaluar la viabilidad del sistema.
• Realizar análisis económicos y técnicos.
• Asignar funciones a los elementos del sistema.
• Establece horarios y restricciones.
• Cree definiciones de sistema.

1.2.2.1 Proceso de análisis de requerimientos

Un proceso de análisis de requisitos implica los siguientes pasos:
1. Reconocimiento del problema

Se deben de estudiar inicialmente las especificaciones del sistema y el plan del

proyecto del software. Realmente se necesita llegar a comprender el software
dentro del contexto del sistema. El analista debe establecer un canal adecuado de
comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la
función primordial del analista en todo momento es reconocer los elementos del
problema tal y como los percibe el usuario.
2. Evaluación y síntesis

En esta etapa el analista debe centrarse en el flujo y estructura de la información,

definir las funciones del software, determinar los factores que afectan el desarrollo
de nuestro sistema, establecer las características de la interfaz del sistema y
descubrir las restricciones del diseño. Todas las tareas anteriores conducen
fácilmente a la determinación del problema de forma sintetizada.
Pregunte a cada una de las partes interesadas y usuarios finales sus requisitos
para el nuevo producto. A continuación, se muestran algunas técnicas de análisis
de requisitos que puede utilizar para capturar los requisitos:
 Realice entrevistas individuales
Entreviste a cada parte interesada y usuario final individualmente. Esta
técnica le ayudará a reunir requisitos específicos.
 Utilice grupos focales
Realice entrevistas grupales o talleres grupales para comprender el flujo de
información entre diferentes partes interesadas y usuarios finales. Esta
técnica garantizará que no haya ningún conflicto de intereses más adelante
durante el proyecto.
 Utilice casos de uso
Los casos de uso proporcionan un recorrido por todo el producto a través
de los ojos del usuario final. Esta técnica ayudará a visualizar cómo
funcionará realmente el producto.
 Construya prototipos
Un prototipo proporciona a los usuarios una apariencia de muestra del
producto final. Esta técnica ayudará a abordar los problemas de viabilidad e
identificar problemas con anticipación.

3. Modelización

Durante la evaluación y síntesis de la solución, se crean modelos del sistema que

servirán al analista para comprender mejor el proceso funcional, operativo y de
contenido de la información. El modelo servirá de pilar para el diseño del software
y como base para la creación de una especificación del software.
Dado que los requisitos pueden ser de varios tipos, deben agruparse para evitar
confusiones. Los requisitos generalmente se dividen en cuatro categorías:
 Requisitos funcionales: funciones que debe realizar el producto.
 Requisitos técnicos: cuestiones técnicas que se deben considerar para la
implementación exitosa del producto.
 Requisitos de transición: pasos necesarios para implementar un nuevo
producto sin problemas.
 Requisitos Operacionales - Operaciones a realizar en el backend para el
correcto funcionamiento del producto.

4. Especificación
Las tareas asociadas con la especificación intentan proporcionar una
representación del software. Esto más adelante permitirá llegar a determinar si se
ha llegado a comprender el software, en los casos que se lleguen a modelar se
pueden dejar plasmados manuales.
5. Revisión
Una vez que se han descrito la información básica, se especifican los criterios de
validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La
documentación del análisis de requerimientos y manuales, permitirán una revisión
por parte del cliente, la cual posiblemente traerá consigo modificaciones en las
funciones del sistema por lo que deberán revisarse el plan de desarrollo y las
estimaciones previstas inicialmente.

1.2.2.2 Técnicas y herramientas de análisis de requerimientos

A continuación, se muestran algunas técnicas para analizar e interpretar los
requisitos:

1.2.2.2.1 Defina los requisitos con precisión

Asegúrese de que los requisitos estén redactados con claridad, lo suficientemente
detallados y relacionados con las necesidades comerciales.

1.2.2.2.2 Priorizar requisitos

Priorice los requisitos y enumérelos en función de cuáles son los "más críticos" y
cuáles son simplemente "agradables".

1.2.2.2.3 Realizar un análisis de impacto

Realice un análisis de impacto para asegurarse de que comprende completamente
las consecuencias de los requisitos.

1.2.2.2.4 Resolver conflictos

Organice una reunión con las partes interesadas clave y resuelva los requisitos en
conflicto. También puede realizar un análisis de escenarios para explorar cómo
funcionarían los requisitos para diferentes escenarios posibles.

1.2.2.2.5 Analizar viabilidad

Realice un análisis detallado del producto basado en los requisitos recopilados
para determinar su confiabilidad e identificar cualquier problema importante.
Una vez analizados todos los requisitos, cree un documento escrito detallado y
distribúyalo entre las partes interesadas clave, los usuarios finales y los equipos
de desarrollo.
1.2.3 Priorización de requerimientos
El proyecto de desarrollo de software al igual que cualquier otro proyecto tiene
múltiples técnicas de priorización de requerimientos, restricciones presupuestarias
y plazos ajustados. Por lo tanto, existe la necesidad de priorizar los requisitos de
software ya que es imposible hacer todo a la vez. Por lo tanto, se deben tomar
decisiones sobre qué conjunto de requisitos se deben implementar primero y
cuáles se pueden retrasar hasta una versión posterior.
En general los procesos de priorización de requerimientos se basan en tres
etapas:
1. Selección de los criterios definidos para priorizar requerimientos. Pueden
ser criterios de negocios como necesidades de los usuarios, costo; o bien
técnicos como factibilidad, recursos existentes, etc.
2. Determinación de un ordenamiento de acuerdo a criterios específicos para
uno o más participantes.
3. Composición de un orden final combinando el punto anterior con varios
participantes.
La estrategia de priorización es como un proceso iterativo que conlleva varios
participantes. En cada iteración para cada requerimiento se analizan los valores
finales asignados a dicho requerimiento. Esto es que para cada requerimiento se
determina un valor final, el cual es la media de los valores finales asignados por
cada participante a ese requerimiento. Utilizando una técnica de asignación de
valores sobre cada uno de los requerimientos, cada persona tendrá un valor
numérico más el valor cognitivo correspondiente para cada uno de los
requerimientos de un conjunto de requerimientos. Para que un participante asigne
un valor a un requerimiento se consideran tres variables:
 Conocimiento del individuo sobre el requerimiento
 Categorización del individuo
 Valor asignado por el individuo

Conocimiento del participante sobre un requerimiento

Lo separamos en 4 niveles (sin conocimiento, poco conocimiento, conocimiento
suficiente, y experto); donde cada nivel tendrá un peso asignado.

Categorización del individuo

Considera la jerarquía del individuo dentro y fuera de la organización. Como en
toda organización existen múltiples niveles de jerarquías, una asignación válida de
peso estará dada por un peso diferente para cada nivel. Para el caso de los
participantes que están fuera de la organización (desarrolladores, clientes) la
asignación será un valor específico entre los valores considerados en la
organización.
Valor asignado
Es un valor entero, que pertenece al conjunto {-9,-8,…-1, 0, 1,…,9}. Cuando el
valor es negativo significa que la implementación de dicho requerimiento influye de
manera negativa en la implementación del sistema.

1.2.3.1 Técnicas y herramientas de priorización de requerimientos

1.2.3.1.1 Dentro o fuera
El método más simple es que un grupo de partes interesadas elabore una lista de
requisitos y decida para cada uno si está dentro o fuera. Consulte los objetivos
comerciales del proyecto para hacer este juicio, reduciendo la lista al mínimo
necesario para la primera iteración o versión. Cuando esa iteración está en
marcha, puede volver a los requisitos anteriores y repetir el proceso para el
siguiente ciclo. Este es un enfoque simple para administrar una acumulación ágil
de historias de usuarios, siempre que la lista de requisitos pendientes no sea
demasiado grande.

1.2.3.1.2 Comparación por pares y ordenación de rangos

Ordenar por rango una lista de requisitos implica hacer comparaciones por pares
entre todos ellos para que pueda juzgar qué miembro de cada par tiene mayor
prioridad. Esto se vuelve difícil de manejar para más de unas pocas docenas de
requisitos. Podría funcionar en el nivel de granularidad de las características, pero
no para todos los requisitos funcionales de un sistema de buen tamaño en su
conjunto.

1.2.3.1.3 Escala de tres niveles

Un enfoque común agrupa los requisitos en tres categorías prioritarias. No importa
cómo los etiquete, si usa tres categorías, se reducirán a prioridad alta, media y
baja. Estas escalas de priorización suelen ser subjetivas e imprecisas. Para que la
escala sea útil, las partes interesadas deben ponerse de acuerdo sobre lo que
significa cada nivel en su escala.
Estas alternativas producen cuatro combinaciones posibles, que puede utilizar
para definir una escala de prioridad:
 1. Los requisitos de alta prioridad son importantes porque los clientes
necesitan la capacidad y urgentes porque la necesitan en la próxima
versión. Alternativamente, puede haber razones comerciales convincentes
para implementar un requisito con prontitud, o las obligaciones
contractuales o de cumplimiento pueden exigir una liberación anticipada. Si
una entrega se puede enviar sin un requisito particular, entonces no es de
alta prioridad según esta definición. Esa es una regla estricta.
2. Los requisitos de prioridad media son importantes (los clientes necesitan la
capacidad) pero no urgentes (pueden esperar una versión posterior).
3. Los requisitos de baja prioridad no son importantes (los clientes pueden
vivir sin la capacidad si es necesario) ni urgentes (los clientes pueden
esperar, quizás para siempre).

1.2.4 Validación de requerimientos

A medida que se crea cada elemento del modelo de requerimientos, se estudia
para detectar inconsistencias, omisiones y ambigüedades. Los participantes
asignan prioridades a los requerimientos representados por el modelo y se
agrupan en paquetes de requerimientos que se implementarán como incrementos
del software.
La validación de requerimientos es el proceso de verificar que los requerimientos
definan realmente el sistema que en verdad quiere el cliente. Se traslapa con el
análisis, ya que se interesa por encontrar problemas con los requerimientos. La
validación de requerimientos es importante porque los errores en un documento
de requerimientos pueden conducir a grandes costos por tener que rehacer,
cuando dichos problemas se descubren durante el desarrollo del sistema o
después de que éste se halla en servicio.
Durante el proceso de validación de requerimientos, tienen que realizarse
diferentes tipos de comprobaciones sobre los requerimientos contenidos en el
documento de requerimientos. Dichas comprobaciones incluyen:
 1. Comprobaciones de validez
2. Comprobaciones de consistencia
3. Comprobaciones de totalidad
4. Comprobaciones de realismo
5. Verificabilidad

1.2.4.1 Técnicas y herramientas de validación de requerimientos

Hay algunas técnicas de validación de requerimientos que se usan
individualmente o en conjunto con otras:
T é cn ica s y h e rra m e in ta s

Revisiones de requerimientos

Ceación de prototipos

Generación de casos de prueba

1.2.4.1.1 Revisiones de requerimientos

Los requerimientos se analizan sistemáticamente usando un equipo de revisores
que verifican errores e inconsistencias.

1.2.4.1.2 Creación de prototipos

En esta aproximación a la validación, se muestra un modelo ejecutable del
sistema en cuestión a los usuarios finales y clientes. Así, ellos podrán
experimentar con este modelo para constatar si cubre sus necesidades reales.
1.2.4.1.3 Generación de casos de prueba
Los requerimientos deben ser comprobables. Si las pruebas para los
requerimientos se diseñan como parte del proceso de validación, esto revela con
frecuencia problemas en los requerimientos. Si una prueba es difícil o imposible de
diseñar, esto generalmente significa que los requerimientos serán difíciles de
implementar, por lo que deberían reconsiderarse. El desarrollo de pruebas a partir
de los requerimientos del usuario antes de escribir cualquier código es una pieza
integral de la programación extrema.