5.

2 Recopilar Requisitos PMBOK

Recopilar Requisitos es el proceso de determinar, documentar y gestionar las necesidades y los requisitos de los
interesados para cumplir con los objetivos del proyecto. Los requisitos incluyen condiciones o capacidades que
el proyecto debe cumplir o que deben estar presentes en el producto, servicio o resultado para satisfacer un
acuerdo u otra especificación formalmente impuesta. Los requisitos incluyen las necesidades y expectativas
cuantificadas y documentadas del patrocinador, del cliente y de otros interesados.

Muchas organizaciones clasifican los requisitos en diferentes tipos, tales como soluciones de negocio y técnicas

• Requisitos de negocio, que describen las necesidades de alto nivel de la organización en su conjunto, tales
como los problemas u oportunidades de negocio y las razones por las que se ha emprendido un proyecto.

• Requisitos de los interesados, que describen las necesidades de un interesado o grupo de interesados.

• Requisitos de las soluciones, que describen las prestaciones, funciones y características del producto, servicio
o resultado que cumplirán los requisitos de negocio y de los interesados.

• Los requisitos de transición describen capacidades temporales, tales como la conversión de datos y los
requisitos de capacitación, necesarias para pasar del estado actual “como es” al estado futuro “como será”.

• Requisitos del proyecto, que describen las acciones, los procesos u otras condiciones que el proyecto debe
cumplir.

• Requisitos de calidad, que recogen las condiciones o criterios necesarios para validar la finalización exitosa
de un entregable del proyecto o el cumplimiento de otros requisitos del proyecto.

El plan de gestión del alcance define con claridad el modo en que los equipos del proyecto han de determinar el
tipo de requisitos que es necesario recopilar para el proyecto.

El plan de gestión de los requisitos define los procesos que se utilizarán para definir y documentar las
necesidades de los interesados a lo largo del proceso Recopilar Requisitos.

El plan de gestión de los interesados se utiliza para comprender los requisitos de comunicación y el nivel de
compromiso de los interesados a fin de evaluar y adaptarse al nivel de participación de los interesados en las
actividades relacionadas con los requisitos.

El acta de constitución del proyecto se utiliza para proporcionar la descripción de alto nivel del producto,
servicio o resultado del proyecto, de modo que se puedan establecer requisitos detallados.

El registro de interesados se utiliza para identificar a los interesados capaces de proporcionar información
acerca de los requisitos.

Una entrevista es una manera formal o informal de obtener información de los interesados, a través de un
diálogo directo con ellos. Se lleva a cabo habitualmente realizando preguntas, preparadas o espontáneas y
registrando las respuestas, puede ayudar a identificar y definir las características y funciones esperadas de los
entregables del producto.

Las entrevistas también son útiles para obtener información confidencial. Los grupos focales reúnen a
interesados y expertos en la materia, previamente seleccionados, a fin de conocer sus expectativas y actitudes
con respecto a un producto, servicio o resultado propuesto. Los talleres facilitados son sesiones focalizadas que
reúnen a los interesados clave para definir los requisitos del producto. se enfocan en reunir a expertos en la
materia del ámbito del negocio y al equipo de desarrollo, para mejorar el proceso de desarrollo de software.
Estas necesidades se clasifican y se ordenan por prioridad de manera objetiva, y se establecen objetivos que
permitan cumplir con ellas.

También se realizan técnicas grupales de creatividad, tales como tormenta de ideas, técnicas de grupo nominal,
mapa conceptual/mental, diagrama de afinidad, análisis de decisiones con múltiples criterios. Así como también
se toman ttécnicas grupales de toma de decisiones ya sea por unanimidad, mayoría, pluralidad, dictadura.

Las observaciones proporcionan una manera directa de ver a las personas en su ambiente, y el modo en que
realizan sus trabajos o tareas y ejecutan los procesos. Son particularmente útiles para procesos detallados,
cuando las personas que usan el producto tienen dificultades o se muestran renuentes para articular sus
requisitos. El desarrollo de prototipos es un método para obtener una realimentación rápida en relación con los
requisitos, mientras proporciona un modelo operativo del producto esperado antes de construirlo. Puesto que
un prototipo es tangible, permite a los interesados experimentar con un modelo del producto final, en lugar de
limitarse a debatir en forma abstracta sobre sus requisitos.

El diagrama de contexto es un ejemplo de un modelo de alcance. Los diagramas de contexto representan

visualmente el alcance del producto al mostrar un sistema de negocio y sus interacciones con las personas y con
otros sistemas.

El análisis de documentos se utiliza para obtener requisitos mediante el examen de la documentación existente
y la identificación de la información relevante para los requisitos. Se puede analizar una amplia variedad de
documentos, que podrían ayudar a obtener requisitos relevantes.

La documentación de requisitos describe cómo los requisitos individuales cumplen con las necesidades de
negocio del proyecto. Los requisitos pueden comenzar a un alto nivel e ir convirtiéndose gradualmente en
requisitos más detallados, Los componentes de la documentación de requisitos incluyen, entre otros: requisitos
del negocio, de los interesados, de soluciones, del proyecto, de transición, supuestos, dependencias y
restricciones de los requisitos.

La implementación de una matriz de trazabilidad de requisitos ayuda a asegurar que cada requisito agrega valor
al negocio, al vincularlo con los objetivos del negocio y del proyecto. En la matriz de trazabilidad de requisitos se
pueden registrar los atributos asociados con cada requisito. Estos atributos ayudan a definir la información clave
acerca de cada requisito.
Capítulo 4.5 de Ingeniería de Software de Somerville

En esta actividad, los ingenieros de software trabajan con clientes y usuarios finales del sistema para descubrir el
dominio de aplicación, qué servicios debe proporcionar el sistema, el desempeño requerido de éste, las
restricciones de hardware, etcétera

En una organización, la adquisición y el análisis de requerimientos pueden involucrar a diversas clases de

personas. Un participante en el sistema es quien debe tener alguna influencia directa o indirecta sobre los
requerimientos del mismo. Los participantes incluyen a usuarios finales que interactuarán con el sistema, y a
cualquiera en una organización que resultará afectada por él.

Las actividades del proceso son:

Descubrimiento de requerimientos Éste es el proceso de interactuar con los participantes del sistema para
descubrir sus requerimientos.

1. Clasificación y organización de requerimientos Esta actividad toma la compilación no estructurada de

requerimientos, agrupa requerimientos relacionados y los organiza en grupos coherentes. La forma más común
de agrupar requerimientos es usar un modelo de la arquitectura del sistema, para identificar subsistemas y
asociar los requerimientos con cada subsistema.

2. Priorización y negociación de requerimientos Inevitablemente, cuando intervienen diversos participantes, los

requerimientos entrarán en conflicto. Esta actividad se preocupa por priorizar los requerimientos, así como por
encontrar y resolver conflictos de requerimientos mediante la negociación.

3. Especificación de requerimientos Los requerimientos se documentan e ingresan en la siguiente ronda de la

espiral.

La comprensión de los requerimientos por parte del analista mejora con cada ronda del ciclo. El ciclo concluye
cuando está completo el documento de requerimientos. La adquisición y la comprensión de los requerimientos
por parte de los participantes del sistema es un proceso difícil por diferentes razones: los participantes con
frecuencia no saben lo que quieren de un sistema de cómputo, excepto en términos muy generales, los
participantes en un sistema expresan naturalmente los requerimientos con sus términos y conocimientos
implícitos de su trabajo, diferentes participantes tienen distintos requerimientos y pueden expresarlos en
variadas formas, factores políticos llegan a influir en los requerimientos de un sistema, el ambiente económico y
empresarial donde ocurre el análisis es dinámico. El descubrimiento 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.

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. Los requerimientos se derivan de las respuestas a dichas preguntas. Las
entrevistas son de dos tipos: Entrevistas cerradas, donde los participantes responden a un conjunto de
preguntas preestablecidas y entrevistas abiertas, en las cuales no hay agenda predefinida.

Las entrevistas son valiosas para lograr una comprensión global sobre qué hacen los participantes, cómo pueden
interactuar con el nuevo sistema y las dificultades que enfrentan con los sistemas actuales. Las entrevistas
tampoco son una técnica efectiva para adquirir conocimiento sobre los requerimientos y las restricciones de la
organización, porque existen relaciones sutiles de poder entre los diferentes miembros en la organización. Los
entrevistadores efectivos poseen dos características: tienen mentalidad abierta, evitan ideas preconcebidas
sobre los requerimientos y escuchan a los participantes e instan al entrevistado con una pregunta de trampolín
para continuar la plática, dar una propuesta de requerimientos o trabajar juntos en un sistema de prototipo.

Sobre los escenarios, por lo general, las personas encuentran más sencillo vincularse con ejemplos reales que
con descripciones abstractas. Pueden comprender y criticar un escenario sobre cómo interactuar con un sistema
de software. Los escenarios son particularmente útiles para detallar un bosquejo de descripción de
requerimientos. 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 sencilla, un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo
de interacción. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos
como una secuencia UML o un gráfico de estado.

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. El
UML es un estándar de facto para modelado orientado a objetos, así que los casos de uso y la adquisición
basada en casos ahora se utilizan ampliamente para adquisición de requerimientos.

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: los 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 y los que se derivan de la cooperación y el conocimiento de las actividades de otras personas.

Los estudios etnográficos pueden revelar detalles críticos de procesos, que con frecuencia se pierden con otras
técnicas de adquisición de requerimientos. Sin embargo, debido a su enfoque en el usuario final, no siempre es
adecuado para descubrir requerimientos de la organización o de dominio.
 SOMMERVILLE
-Clasifica los tipos de requerimientos en base al
modelo de la arquitectura del sistema.
-Se menciona la necesidad de la priorización de
requerimientos.
-Muestra la dificultad de la adquisición y
comprensión de requerimientos.
-Da ejemplos del descubrimiento de requerimientos.
-Muestra herramientas de recopilación como la
entrevista, los tipos y menciona su efectividad, así
como también las características de los
entrevistadores.
-Se menciona el uso de escenarios para la
formulación de requerimientos, así como muestra
un ejemplo.
-Se detecta los casos de usos y su función, así como
la efectividad de estos.
-Menciona el uso de la etnografía para entender
procesos operacionales y derivar requerimientos.
PMBOK
-Clasifica los tipos de requerimientos por tipos.
--Muestra los distintos tipos de planes de gestión
para la recopilación de requisitos.
-Muestra herramientas para la recopilación de
requisitos como grupos focales, entrevistas y
talleres facilitados.
-Plasma las diferentes técnicas grupales de
creatividad, así como también para la toma de
decisiones.
-Se menciona el uso de prototipos.
-Se menciona el uso de estudios comparativos.
-Se menciona el uso de diagramas de contexto.
-Describe en que se basa la documentación de
requisitos y los componentes necesarios.
-Muestra la factible que es el uso de la matriz de
trazabilidad de requisitos para su definir
información clave.

Conclusiones personales:

Terminando esta actividad puedo decir que ambos libros me parecen interesantes y útiles para saber cómo hay
que identificar los requerimientos a la hora de diseñar un software, sin embargo puedo mencionar que creo que
se complementan, puesto que un carece de puntos y/o ejemplos necesarios que el otro no. A mi gusto personal
usaría el PMBOK pues siento que muestra los pasos detalladamente a la hora de identificar requerimientos, así
como menciona las técnicas, que el libro de summerville no menciona, y aunque el PMBOK carece de ejemplos
que para primerizos creo que sería fundamental la implementación de estos y necesarios para el entendimiento
de ciertos puntos. Fuera de la comparación de estos libros y mi punto de vista. Puedo decir que indirectamente
se me quedaron grabados varias cosas ,al realizar las actividades, y pues me parece interesante las técnicas y
herramientas necesarias para el descubrimiento de requerimientos y priorización de estos ,así como también
descubrí términos que no conocía y mucho menos sabía su significado, como lo fue la etnografía que me parece
un punto bastante importante y necesario, así como también siento que tiene mucha utilidad la matriz de
trazabilidad para el mejor entendimiento y ordenamiento de los requisitos del software identificados.