Logo Studenta

Analisis y Diseno-2019 (4)

Vista previa del material en texto

Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 1 
UNIDAD VII 
ANALISIS Y DISEÑO DE SISTEMAS 
1. Técnicas para el análisis de requerimientos de software 
En la Ingeniería de requisitos, el análisis de los requerimientos del software es la etapa 
que sigue después que estos han sido levantados y documentados en un registro o matriz de 
trazabilidad. (Plantilla de matriz de trazabilidad, archivo .xls en plataforma Slack). La matriz 
de trazabilidad de requisitos es un cuadro que vincula los requisitos del proyecto desde su 
origen hasta los entregables que lo satisfacen. La matriz de requisitos ayuda a asegurar que 
cada requerimiento agrega valor al negocio, mostrándote el vínculo entre requisitos, 
necesidades de negocio y objetivos de proyecto. De esta forma puedes hacer un seguimiento 
durante el ciclo de vida, mejorando la ingeniería de requisitos al asegurar que estos sean 
entregados según especificaciones. 
La especificación de requerimientos, es una actividad que cada vez toma mayor 
preponderancia en la gerencia de proyectos, dado que se ha demostrado que una causa 
recurrente en su fracaso se origina de una inadecuada especificación de requisitos. 
El análisis de requerimientos consiste en aplicar una serie de técnicas para desglosar y 
analizar los requisitos y sus partes, algunas de estas técnicas son: Modelado de procesos, 
Modelado de dominio, casos de uso, inspecciones, listas de chequeo y prototipos. 
a) Descomposición funcional 
La descomposición funcional se refiere al proceso de identificar y resolver las relaciones 
funcionales en sus partes constituyentes, de tal forma que la función global pueda ser 
reconstruida a partir de sus partes. 
Por lo general, la descomposición funcional se realiza para identificar y entender los 
componentes o partes que constituyen un todo (o función global). 
En este proceso, es vital identificar las interacciones entre componentes. 
Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de software, 
dividirlos en partes y analizarlos individualmente. De ser necesario, se pueden descomponer 
en más partes hasta lograr un nivel adecuado de detalle. 
En cierto sentido, el proceso es similar al de la elaboración de una estructura de 
desglose de trabajo de un proyecto. 
En Ingeniería de sistemas, la descomposición funcional consiste en definir un sistema 
en términos funcionales, para luego definir funciones de más bajo nivel y establecer las 
relaciones con estas funciones de alto nivel. 
La intención es dividir un sistema de tal forma que cada componente se pueda describir 
sin necesidad de referir a otro componente. 
De esta forma, cada parte del sistema tendrá funciones independientes, que pueden 
reusarse y reemplazarse. 
Plantilla de estructura de desglose de trabajo (EDT) 
 
La Estructura de Desglose del Trabajo (EDT) es una descomposición jerárquica del 
alcance total del trabajo a realizar en un proyecto, para cumplir con sus objetivos y crear sus 
entregables. 
 
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 2 
La Estructura de Desglose del Trabajo, permite subdividir los entregables y el trabajo 
del proyecto en componentes más pequeños y fáciles de manejar, proporcionando una visión 
estructurada de lo que se debe entregar. Organiza define el alcance total del proyecto y 
representa el trabajo especificado en el enunciado del alcance del proyecto aprobado y 
vigente. 
 
Se elabora a partir del enunciado del alcance y la documentación de requisitos del 
proyecto 
 
 
 
b) Especificación vía Sentencias Textuales 
Es la forma tradicional de la especificación de requerimientos de software. 
Se usan especificaciones textuales en lenguaje natural, que se documentan en matrices 
de trazabilidad de requerimientos o definiciones del alcance. 
El procedimiento consiste en tomar el requerimiento producto del levantamiento de 
información, para desarrollar una narrativa más detallada. 
No usa herramientas visuales como los flujogramas o estructura como los casos de uso, 
es simplemente una descripción más detallada del requerimiento en lenguaje natural. 
 
c) Modelado del Proceso 
• Comprende la elaboración de diagramas de flujo de procesos (Flujogramas) a partir de los 
requerimientos del software. 
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 3 
• Existen diversas herramientas de modelado de procesos, cada una de las cuales posee 
sus propios símbolos y reglas. 
• Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y 
departamentos intervinientes. 
• Los procesos son iniciados por eventos y pueden abarcar actividades automatizadas, 
manuales o combinación entre ambas. 
• Su naturaleza visual ayuda a la comprensión y comunicación a terceros. 
• Cuando los procesos son complejos, deben desglosarse en componentes (subprocesos). 
• La relación entre los diagramas de flujo y la gerencia de proyectos es fundamental 
para el éxito. 
 
d) Modelo de dominio 
 
 
Imagen de: Wikipedia 
• En Ingeniería de software, en análisis de dominio consiste en analizar sistemas o software 
relacionados en un dominio, con la finalidad de encontrar sus partes comunes y partes que 
los diferencian. 
• Produce un modelo de contexto de negocio para todo el sistema. 
• Un modelo de dominio comprende diagramas conceptuales que incluyen tanto el 
comportamiento de un sistema como sus datos. 
• Un tipo de modelo de dominio son los diagramas de funcionalidades (Features Diagrams), 
que es una representación “compacta” del sistema o aplicación en términos de sus 
características. 
• El análisis de dominio produce modelos orientados a objetos o modelos relacionales de 
datos, que pueden ser usados por los desarrolladores de software como base 
de arquitecturas de software y aplicaciones. 
 
Casos de Uso 
 
https://en.wikipedia.org/wiki/Feature_model
http://www.pmoinformatica.com/2013/10/el-rol-del-arquitecto-de-software.html
https://1.bp.blogspot.com/-gsyn22AQmZM/V6jKnAFPsmI/AAAAAAAAEag/ds22SQ37MJIL614EWQyz9s4VM5i461HmQCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Diagrama+de+funcionalidades.jpg
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 4 
 
Imagen de: Microsoft Developer Network (MSDN) 
• En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de 
interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. 
 
Plantilla para elaborar casos de uso 
 
• En el ámbito académico y profesional, es una de las técnicas demayor difusión para 
especificar el comportamiento del Sistema. 
• Formato simple y estructurado que puede ser compartido entre usuarios y desarrolladores. 
• Además de usarse para analizar los requerimientos de software, también pueden usarse 
en el diseño del sistema e inclusive para definir pruebas de caja negra (Testing). 
• Son útiles en sistemas informáticos orientados a la funcionalidad (transacciones con el 
usuario), que se van a implementar orientados a objetos y con UML. 
• No son la mejor opción en sistemas sin usuarios, o dominados fundamentalmente 
por requerimientos no funcionales. 
 
Checklists 
 
• La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones que se 
realizan sobre los requerimientos de software, que nos sean presentados de forma escrita. 
• Una lista de chequeo puede realizar preguntas como: 
o ¿Se han especificado los requisitos de hardware y software? 
o ¿Se han realizado consideraciones de seguridad? 
o ¿El nivel de granularidad del requerimiento se ha incluido? 
o ¿Se ha incluido el código de referencia en para identificar el requisito en el desglose de 
requerimientos? 
o ¿Está escrito el requerimiento en un lenguaje claro y conciso? 
o ¿El requerimiento es único? (no existe duplicidad con otro requerimiento). 
o Y muchas preguntas más. 
• La lista de chequeo sirve de marco de trabajo y procedimental para revisar el requerimiento, 
facilitando su análisis de forma estructurada. 
• Los requerimientos se pueden revisar sobre la matriz de trazabilidad de requerimientos o 
sobre la definición del alcance. 
https://msdn.microsoft.com/es-es/library/dd409427.aspx
https://3.bp.blogspot.com/-lhv3NzcIlw0/V6jKWzpMryI/AAAAAAAAEac/T5wHnkT2jcYTmw0fK4Eu18gQ2hlQx8IZgCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Casos+de+uso.png
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 5 
 
Inspección 
 
• Revisión no destructiva de los requerimientos de software. Por ejemplo: 
o Examinar un software visualmente para constatar que las pantallas solicitadas se 
encuentran incluidas. 
o Verificar la inclusión de los campos necesarios para el ingreso de datos. 
o Verificar la existencia de los botones necesarios para iniciar la funcionalidad que ha sido 
requerida. 
o Verificar que el requerimiento se apega a los estándares definidos para la aplicación. Por 
ejemplo estándares de navegación entre pantallas y estándares de interfaz gráfica. 
• De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el 
requerimiento definido en la matriz de trazabilidad o definición de alcance, leerlo y producir 
un resultado para su corrección. 
 
Prototipos 
 
 
Designed by Freepik 
• Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de los 
requerimientos de software. 
• Es una herramienta muy útil para validar con los usuarios, clientes e interesados de 
proyecto que el diseño funcional corresponde con los requerimientos de software (Que existe 
entendimiento común entre desarrolladores de software y usuarios). 
• Permite a desarrolladores y usuarios entender mejor los requerimientos, determinar cuáles 
son indispensables y cuales deseables, e identificar riesgos de forma temprana. 
• Puede enfocarse en toda la solución o sólo en áreas específicas. 
• Puede extenderse innecesariamente en el tiempo si las discusiones se realizan en torno al 
como en lugar de en torno al que. 
• La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios, en los 
cuales se van elaborando varios prototipos y sometidos a evaluación del cliente. 
 
 
https://2.bp.blogspot.com/-V4Krr02103I/V6jMHtWihJI/AAAAAAAAEaw/nVsV178EIcgD7q_IeoRCiAp1BSJVxx72gCLcB/s1600/T%C3%A9cnicas+de+an%C3%A1lisis+de+requerimientos+-+Prototipos.jpg
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 6 
Gerencia de los Interesados (Stakeholders) 
La ingeniería de requisitos en un proyecto está íntimamente relacionada con la gerencia 
de los interesados (stakeholders), pues son quienes originan los requisitos y tienen mayor 
influencia en su aceptación. 
La Gestión de los interesados del proyecto (Stakeholders), es una función que cada vez 
adquiere mayor importancia en la Gerencia de proyectos, pues ha quedado demostrado que 
lograr la participación eficaz de los interesados en la ejecución y toma de decisiones es 
fundamental para el éxito. 
La gestión eficaz de los interesados del proyecto parte de la oportuna identificación 
y mantenimiento de un registro de los mismos, para lo cual el Gerente de proyectos cuenta 
con un instrumento que se denomina registro de los interesados. 
 
En él se documenta información sobre los datos de contacto de cada uno de los interesados, 
sus requerimientos, expectativas, evaluación de su grado de influencia, interés y postura (a 
favor o contraria) entre otros aspectos 
Descripción de la plantilla del registro de los interesados 
Información de identificación 
 
• Nombre: Nombre y apellido completo del interesado. 
• Posición: Posición o cargo que la persona desempeña en la organización. 
• Organización / Empresa: Los interesados pueden pertenecer a la misma organización 
que ejecuta el proyecto o a otras relacionadas, tales como: clientes, proveedores, entes 
gubernamentales y asociaciones civiles. Aquí se registra a que organización pertenece el 
interesado y el departamento o unidad organizacional. 
• Ubicación: Localización geográfica del interesado, por ejemplo la ciudad o región en la 
cual esta su oficina. 
• Información de contacto: Datos necesarios para poder ubicar a la persona, por ejemplo 
dirección exacta de correo (físico), dirección de correo electrónico, teléfono fijo, teléfono móvil, 
nombre de usuario de chat o Skype y cualquier otra información necesaria. 
 
Información de evaluación 
• Requisitos principales: Aquí se escribe que es lo principal que el interesado requiere 
del proyecto en términos de entregables o información. Usualmente se relaciona con 
los requerimientos detallados que se levantan en la fase de identificación de 
requerimientos (que forma parte de la definición de alcance del proyecto). 
• Expectativas principales: Beneficios que el interesado espera obtener del proyecto, 
o también que esperan ganar (o perder) como consecuencia del proyecto. Balancear 
las expectativas de todos los interesados puede llegar a ser todo un reto para la 
Gerencia de proyectos 
• Grado de influencia: Es el grado de "poder" que el interesado tiene para afectar 
positiva o negativamente el resultado o éxito del proyecto 
• Grado de interés: Es el grado en el cual el interesado es afectado positiva o 
negativamente (según su punto de vista) por el proyecto, pudiendo ser Bajo, Medio y 
Alto. 
• Fase de mayor interés: Fase del ciclo de vida del proyecto en la cual el interesado 
está más involucrado, concentra sus intereses o tiene mayor grado de actividad. 
 
 
 
 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 7 
 
Clasificación 
 
 
• Interno / Externo: Los interesados internos son personasy grupos que trabajan 
directamente en la organización ejecutora del proyecto, como por ejemplo empleados, 
gerentes y los dueños de la empresa. Los interesados externos son personas o grupos no 
directamente relacionados con la organización, pero que tienen interés e influencia, por 
ejemplo accionistas, entes gubernamentales, proveedores o subcontratistas, grupos de la 
sociedad (asociaciones civiles), clientes y acreedores. 
• Partidario / Neutral / Reticente: Un aspecto importante de la gerencia de interesados es 
poder identificar la postura de estos frente al proyecto, dado que las estrategias de gestión de 
cada interesado pueden variar dependiendo si el interesado ejerce su influencia para 
favorecer el proyecto, obstaculizarlo o se muestra neutral. 
Como lidiar con implicados (stakeholders) problemáticos 
Todo proyecto de cualquier área tendrá que enfrentar tarde o temprano algún participante o 
implicado problemático (Ej. Usuarios finales, Clientes, jefes de departamento, integrantes de 
equipo, etc.), diversas pueden ser las situaciones, amenaza para la agenda personal, 
estabilidad, resistencia al cambio o a las nuevas tecnologías. 
 
Para lidiar con esto, en primer lugar debe entenderse su visión de la organización, 
motivaciones y objetivos, para luego desarrollar estrategias en función de sus niveles de 
influencia y participación en el proyecto. 
 
Presentamos a continuación algunas estrategias para entender las motivaciones de 
implicados problemáticos, contrarrestar su influencia e inclusive ganar su cooperación. 
 
Entender las motivaciones y niveles de influencia de los implicados (stakeholders) 
• Dedicar tiempo a entender las motivaciones detrás de la crítica y resistencia. 
• Conversar con el staff (subalternos) y pares. 
• Entender claramente sus metas y objetivos, colocando especial atención en el trabajo que 
hacen en la organización, como lo hacen y como les afecta el proyecto. 
• Determinar cuáles son sus expectativas y lo que espera ganar del proyecto. 
• Colóquese en los zapatos del implicado, entienda su visión de la organización y del 
proyecto. 
• Determine si el proyecto le agrega o quita valor a su área funcional de alguna forma. 
• Si participa directamente en el proyecto, preguntarle que problemas ha encontrado 
realizando el trabajo. 
• Identificar si existe alguna manera de satisfacer sus objetivos sin poner en riesgo el éxito 
del proyecto. 
 
Estrategias para lidiar con implicados problemáticos cuando su participación es clave 
• Darse cuenta que no es posible complacer a todos los implicados en todos los aspectos 
del proyecto. 
• Los objetivos y metas del proyecto deben ser claros y establecidos al principio del 
proyecto. 
• Involucrar a todos los implicados claves desde el principio del proyecto, haciéndoles 
participar en la toma de decisiones. 
• Tome en cuenta las expectativas de los implicados claves. 
• Asegure la transparencia en la forma de llevar el proyecto y evite agendas ocultas. 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 8 
• Cuando modificaciones aceptables al proyecto eliminen las objeciones de ciertos 
implicados, realizar dichas modificaciones, de esta forma, podría transformarse su opinión 
negativa en neutral o positiva. 
• Si es posible, alinear los objetivos y el valor proporcionado por el proyecto con los puntos 
de interés de los implicados, siempre y cuando no estén en conflicto. 
 
Estrategias para lidiar con implicados problemáticos no claves y de baja influencia 
• Aunque su participación no sea clave, las expectativas deben ser tomadas en cuenta para 
evitar resistencia. 
• Si es posible, evite la participación de implicados negativos en actividades críticas del 
proyecto. 
• Realicé alianzas con otros implicados que estén de acuerdo con el proyecto, ellos podrían 
ayudar a convencerlo de los beneficios del proyecto. 
• Hacer seguimiento y cumplir con los compromisos asumidos con los implicados. 
• Ganar su confianza manteniéndoles informados de los avances del proyecto. 
 
Conclusión 
 
Las grandes organizaciones son complejas redes de relaciones, alianzas, agendas 
personales, grupos de poder y niveles de influencia. Implicados problemáticos cuya 
participación es clave para el éxito del proyecto deben ser atendidos de inmediato con 
estrategias directas. 
 
Flujograma de procesos y gerencia de proyectos 
 
Según un estudio del Project Management Institute (PMI), presentado en el PMI Pulse of the 
Profession 2015, el 40% de los fracasos en los proyectos están siendo ocasionados por 
inexactitudes en el levantamiento y documentación de la ingeniería de requisitos. 
 
La experiencia ha demostrado que al utilizar el modelado de flujogramas en la ingeniería de 
requerimientos, se pueden identificar con mayor facilidad los puntos clave, establecer las 
relaciones entre requerimientos y lograr un entendimiento común entre todas las partes del 
producto final que aportará tu proyecto. 
 
Aquel dicho que reza que “una imagen vale más que mil palabras” es muy aplicable a la 
ingeniería de requerimientos, por lo cual dedicamos este artículo a describir la importancia del 
modelado visual y cómo podemos utilizarlo para mejorar la definición de alcance y 
descripciones de las necesidades de los interesados, para así garantizar el éxito de los 
proyectos. 
 
¿Tienen relación la elaboración de flujogramas con la gerencia de proyectos? 
 
El Project Management Intitute (PMI) y su metodología PMI para la dirección de proyectos 
reconocen la ingeniería de requisitos como un aspecto fundamental para determinar las 
necesidades de los interesados, para así definir un alcance que logré aportar valor a sus 
operaciones. 
 
La guía de dirección de proyectos del PMI, el PMBOK 5ta edición, reconoce procesos para 
recopilar los requisitos de los interesados (Proceso 5.2) y posteriormente definir el alcance a 
partir de los mismos (proceso 5.3). 
Los flujogramas de procesos están definidos como herramientas de la dirección de proyectos 
para recopilar requisitos y definir alcance, y como veremos a continuación pueden ayudarte 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 9 
en una mejor definición que se corresponda con las expectativas de los interesados. 
 
El reconocimiento del PMI de está realidad inclusive ha motivado el desarrollo de una 
nueva certificación de Profesional en Análisis de Negocio del PMI (PMI-PBA) 
Qué es un flujograma de procesos? 
Un flujograma, incluye los pasos de un determinado proceso que se quiera representar, 
interconectados con flechas que indican las posibles direcciones o rutas que puede seguir. 
 
Aquí en la imagen presentamos un ejemplo. 
 
 
Los flujogramas manejan otros símbolos, por ejemplo decisorios para representar escenarios 
que pueden seguirse. 
También se pueden representar los entregables o documentos que produce un determinado 
proceso. 
 
¿Cuáles son los beneficios de usar los flujogramas en la ingeniería de requisitos? 
• Los flujogramas de procesos pueden ayudarte a poder discernir las descripciones de los 
requerimientos de los interesados, transformando esas extensas cantidades de texto en 
“historias” que pueden leerse fácilmente. 
• Es más fácil analizar y discutir un flujograma que una descripción extensa de requisitos. 
• Cuando representamos los requerimientos en descripciones de texto, las relaciones entre 
ellos suelen opacarse. Con un flujograma puedes reconocer donde estas relaciones ocurren, 
identificando puntos clave, que podríanrepresentar riesgos para la operación de los clientes 
del producto final de tu proyecto. 
• Los modelos visuales ayudan a identificar donde pueden existir posibles redundancias 
en las funcionalidades y datos, para mejorar así las definiciones de requisitos y alcance. 
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 10 
• En muchas ocasiones los requisitos no están definidos con claridad, ni siquiera por 
los interesados que tienen la necesidad. El modelado visual de un flujograma de proceso 
puede ayudarnos en las mesas de trabajo con las áreas clientes, para hacer las preguntas 
adecuadas y desarrollar un entendimiento común de sus necesidades. 
• Al aportar una visibilidad del panorama completo, abstrayéndonos de detalles técnicos, 
los modelos de flujograma pueden ayudar a los interesados a identificar requerimientos 
faltantes que no se les hayan ocurrido todavía. 
 
¿Qué ocurre si no tengo tiempo de detenerme e invertir considerable tiempo en 
representar los requisitos como flujogramas? 
Es potestad de la Gerencia de proyectos el decidir que modelos visuales usar, cuando usarlos 
y que tan detallados hacerlos. Al igual que con un libro de recetas, puedes tomar solo lo que 
necesitas y hacer tu propio récipe. 
A veces el modelado puede verse como una actividad extenuante, que nos consume mucho 
tiempo, que no tenemos pues la gerencia y los interesados conceden muy poco tiempo 
para elicitar los requisitos de un proyecto. 
Sin embargo, invertir un poco más de tiempo en esto al principio te ahorrará dolores de cabeza 
y retrasos al final, por lo que definitivamente es recomendable no obviar este paso. 
Si no haces el modelado visual al principio, tarde o temprano tendrás que elaborarlo de todas 
formas, bien sea cuando te reúnas con los ejecutores para identificar la causa de algún 
defecto, o cuando tengas que explicarles a los interesados cual fue tu entendimiento del 
requerimiento y que les entregaras. 
 
Lo que si puedes hacer, es ir elaborando prácticas y procedimientos para que puedas elaborar 
estos flujogramas con mayor eficiencia. Puedes ir creando una base de plantillas de 
flujogramas, que puedas archivar. Estas plantillas estarán disponibles para futuros proyectos. 
 
¿Qué otros modelos visuales pueden usarse en la ingeniería de requerimientos? 
 
Además de los flujogramas, existen otras herramientas visuales que puedes usar para 
documentar los requisitos de los interesados en la gerencia de proyectos. 
 
Algunas de las más usadas son las tablas, flujogramas, matrices, diagramas de árbol, modelos 
de objetivo de negocio y muchas otras. 
A continuación te describimos dos de ellas: 
Modelo de objetivos de negocio 
Muy útiles para representar visualmente cual es el valor que está aportado el producto final 
de tu proyecto a los interesados. 
Aquí un ejemplo: 
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 11 
 
 
 
Los modelos de objetivos concatenan problemas que enfrenta el cliente con objetivos de 
negocio específicos para atender esos problemas, y luego se relacionan con un concepto de 
producto. 
 
Al definir estos objetivos de negocio es recomendable usar métricas de éxito. 
 
Arboles de funcionalidades 
Permiten organizar las funcionalidades de un producto y agruparlas, capturando todo el 
alcance de un proyecto en un modelo visual de alto nivel. 
 
Aquí presentamos un ejemplo: 
 
 
 
http://2.bp.blogspot.com/-w0ib6QdwDNg/VZl-YnMLpuI/AAAAAAAADy8/m_4Bjrj3NTc/s1600/Modelo+de+objetivos+de+negocio+600.png
http://4.bp.blogspot.com/-VkgsHStxW_k/VZl15XLKOuI/AAAAAAAADyk/ggw7Gj7yLWg/s1600/Arboles+de+funcionalidades+600.png
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 12 
ARQUITECTURA DE SOFTWARE 
El rol del Arquitecto de software 
Al principio, podía pensarse que simplemente se había “remarcado” el rol del Analista 
de Sistemas, sin embargo, hoy en día existen multitudes de títulos de arquitecto, como: 
Arquitecto Empresarial, Arquitecto de Aplicación, Arquitecto de Soluciones, Arquitecto de 
Tecnología de Información, Arquitecto de Datos, etc. 
 
Pmoinformatica.com, "La Oficina de Proyectos de Informática", presenta: algunos 
comentarios sobre cuáles son las funciones de los Arquitectos de Software en la actualidad. 
 
Qué hace un Arquitecto de Software 
• Revisa las necesidades del negocio junto con los requerimientos no funcionales, y 
los relaciona con la solución que se necesita implementar para cubrirlas. 
• Se asegura de la calidad de la solución y de su mantenimiento en el tiempo. 
• Toma decisiones de diseño de alto nivel. 
• Dicta estándares técnicos, de codificación, herramientas y plataformas. 
 
Los diferentes arquitectos de software 
• Arquitecto Empresarial: Maneja la interacción entre el lado del negocio y de Tecnología 
de Información en la organización. Es el principal encargado en determinar la situación actual 
(AS-IS) y el estado deseado (TO-BE) desde la perspectiva del negocio y Tecnología de 
Información. 
• Arquitecto de Aplicación: Es un arquitecto de Software que trabaja con una sola de 
las aplicaciones de la solución (Los proyectos pueden implicar múltiples aplicaciones). 
Puede ser u rol tiempo parcial o completo. En la mayoría de los casos, el arquitecto de 
aplicación es un desarrollador de software activo en el proyecto. 
• Arquitecto de Solución: A diferencia del Arquitecto de Aplicación, el Arquitecto de 
Soluciones trabaja con todas las aplicaciones, cuyas interacciones son necesarias para 
suministrar la solución completa al cliente. 
• Arquitecto de Tecnología de Información (TI): Es quien decide cuales recursos de TI 
serán aplicados para satisfacer las necesidades del negocio, tomando en cuenta la eficiencia 
operacional y organizacional, por medio de la integración y gestión de la información. El Rol 
implica tanto habilidades en software de información como en la infraestructura de TI. 
• Arquitecto de Datos: Es el responsable de asegurar que los datos de la organización se 
soporten en una arquitectura de datos que apoye a la organización en el logro de sus objetivos 
estratégicos. La arquitectura de datos debe cubrir tanto las bases de datos como la 
integración, es decir los medios para acceder a los datos. Entre las muchas funciones está 
incluido el modelado de los datos. 
 
Todo desarrollador debe ser un arquitecto 
 
No necesariamente, hoy en día existe la tendencia a creer que todo desarrollador debe 
tener habilidades de Arquitecto, eso en sí no es un problema, sin embargo no todos los 
desarrolladores son buenos arquitectos. 
 
No es un asunto de capacidad, simplemente algunos desarrolladores son buenos resolviendo 
problemas específicos que requieren profundización, mientras que otros son buenos 
manejando mayores niveles de abstracción. 
 
 
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 13 
La Tecnología cambia rápidamente 
Otro reto para los arquitectos de Software es la rapidezcon la que surgen nuevas tecnologías 
y productos. Todo arquitecto necesita invertir grandes cantidades de tiempo personal, 
solamente para mantenerse al día. 
 
Las Funciones del Arquitecto de Software 
 
• Elaborar la arquitectura y diseño de software a partir de los requerimientos del usuario. 
Haciendo uso de patrones de diseño previamente conocidos, por experiencia personal o 
manteniéndose actualizado con las últimas técnicas y patrones. 
• Crear consenso y entendimiento de la arquitectura. Debe involucrar a cada miembro del 
equipo, y lograr acuerdos respecto a la arquitectura, la cual debe comunicar y vender. 
• Entender los requerimientos no funcionales: 
o La mayoría de los requerimientos no funcionales son de naturaleza técnica, y suelen tener 
mucha influencia en la arquitectura. 
o El entendimiento adecuado de estos requerimientos es crucial para desempeñar este rol. 
o No basta con asumir cuales son esos requerimientos, se necesita indagar sobre ellos y 
determinar las necesidades reales. 
• Definir la Arquitectura: 
o Incluir estructuras, lineamientos, principios y liderazgo sobre los aspectos técnicos del 
software. 
o Esta responsabilidad varía mucho si se está trabajando con un sistema con arquitectura 
definida frente a diseñar un nuevo sistema. 
• Seleccionar Tecnologías: 
o Puede llegar a ser un reto, considerando todos los elementos a considerar: costo, 
licenciamiento, relaciones con proveedores, estrategia de tecnología, compatibilidad, 
interoperabilidad, soporte, instalación, políticas de actualización, ambientes de usuario final, 
etc. 
o Seleccionar tecnologías se trata de evaluar los riesgos, reduciéndolos cuando existe alta 
complejidad e incertidumbre y aumentarlos cuando existen beneficios (oportunidades). 
o Todos los componentes deben ser evaluados, incluyendo los bloques generales, hasta el 
detalle de librerías y frameworks. 
o Toda decisión de tecnología debería ser revisada y aprobada. 
• Evaluar Arquitecturas: 
o Al diseñar el software, el arquitecto debe preguntarse si la arquitectura seleccionada podrá 
satisfacer los requerimientos funcionales y en especial los no funcionales. 
o Las arquitecturas también se pueden probar, y si hacemos esto al principio, podemos evitar 
el fracaso del proyecto. 
 
Diferencias entre el Arquitecto de Software del Líder de Desarrollo 
• El líder de desarrollo se enfoca en conocimiento detallado de áreas específicas 
mientras que el arquitecto de software necesita ver los problemas de forma amplia, desde 
diferentes perspectivas, enfocándose en integrar las partes en una red que permita solucionar 
el problema global. 
• El Arquitecto de Software maneja el problema y la solución a una mayor escala y nivel 
de abstracción. 
• Sus decisiones tienen mayor impacto en la duración del proyecto y los riesgos. 
• Hacer Arquitectura de Software es tener una visión holística, ver el panorama amplio, 
para entender como funcional el sistema como un todo. 
 
http://www.pmoinformatica.com/2013/01/requerimientos-no-funcionales-porque.html
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
nicoj
Resaltar
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 14 
 
Diferentes Funciones según el tipo de Arquitecto de Software 
Según el arquitecto sea Empresarial, De Aplicación o de Solución, manejará distintos niveles 
de complejidad, como se muestra en la siguiente tabla que obtuvimos de Wikipedia. 
Tipo de 
Arquitecto 
Pensamiento 
Estratégico 
Interacciones 
entre Sistemas 
Comunicaciones Diseño 
Empresarial Entre 
Proyectos. 
Altamente 
abstracto. 
En toda la 
organización. 
Mínimo, de Alto 
Nivel. 
Soluciones Enfocado en 
una solución. 
Muy detallado. Múltiples 
equipos de 
Proyecto. 
Detallado. 
Aplicaciones Reutilización y 
mantenimiento 
de 
componentes. 
Centrado en 
una sola 
aplicación. 
Un solo equipo 
de proyecto. 
Muy detallado. 
 
Posibles candidatos 
 
Los posibles candidatos son Líderes de Desarrollo o Desarrolladores de nivel avanzado, que 
durante su evaluación puedan mostrar: 
 
• Varios años de experiencia en la tecnología de desarrollo de software que se está 
buscando. 
• Ejecución de forma consistente y continua de proyectos exitosos en la tecnología de 
software o soluciones que se está buscando. 
• Invierten tiempo en el autoaprendizaje de las mejores prácticas de desarrollo y se 
mantienen actualizados en los patrones de diseño e ingeniería de software. 
• Invierten tiempo en mantenerse actualizados en las últimas tecnologías de informática 
y desarrollo de software. 
• Abordan la arquitectura de software con enfoque crítico y demuestran tener criterio 
propio. 
• Muestran interés en que su propio desarrollo y el de sus pares se apegué a 
los patrones de diseño e ingeniería de software. 
 
Los candidatos a Arquitectos de Software también pueden ser personas que desarrollaron 
pequeños proyectos en los cuales eran el único desarrollador (desempeñaban la función de 
Arquitecto y Desarrollador simultáneamente), por supuesto siempre tomando en cuenta la 
capacidad y tecnología. 
 
Herramientas que debe manejar 
• Lenguaje de documentación visual (ej. UML). 
• Diseño de Base de datos. 
• Procesos y herramientas de desarrollo. 
 
Aspectos positivos de ser un Arquitecto de Software 
• Es un rol clave que tiene potencial de agregar mucho valor si se desempeña 
adecuadamente, lo cual implica por lo general mayor sueldo. 
• Debe interactuar con personas clave en la organización, equipo de desarrollo y 
comunidad de usuarios, por lo que es un rol bastante visible. Esto implica mayores 
oportunidades de carrera. 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 15 
 
Retos a enfrentar 
• Uno de los principales problemas que enfrenta un arquitecto de software en el día a 
día, son los requerimientos funcionales con información incorrecta o incompleta. Requiere de 
mucha habilidad el poder identificar requerimientos mal documentados antes que sea 
demasiado tarde. 
• Para ser un buen arquitecto de software, es necesario estar en constante estudio de 
las nuevas técnicas, patrones y herramientas. Para lograr esto se requiere esfuerzo, 
incluyendo sacrificios de tiempo personal y familiar para invertirlo en autoestudio, cursos, entre 
otros. 
• El rol implica balancear tantos factores que “es muy fácil fracasar”, si esto ocurre, uno 
de los primeros que tendrá que rendir cuentas es el Arquitecto de Software, por lo que “el reto 
es no fracasar”. 
• Con frecuencia, la complejidad del rol es subestimada, por lo que corresponde al 
Arquitecto ser un buen comunicador para demostrar el valor agregado del diseño y 
arquitectura en el proceso de desarrollo de software. 
 
IDENTIFICACION DE RIESGOS 
Todo proyecto siempre posee niveles de incertidumbre sobre la actividad a realizar y el 
producto a entregar, son riesgos que deben ser gestionados. 
 
Se exploran cinco preguntas y respuestas sobre la identificación de los riesgos en un proyecto, 
incluyendo quien debe participar, cuando debe hacerse, cuando termina (o más bien no 
termina) la identificación de riesgos, la importancia de la creatividad, el pensamiento 
innovador, herramientas y técnicas para la identificación de los riesgos. 
 
El verdadero valor de un plan de riesgos, no reside en el cálculo de valor monetario, sino en 
la identificación de todos los riesgos y en la definición de planes de respuesta. 
 
Identificar riesgos en un proyecto no se trata sólo de herramientas y técnicas, la creatividad, 
el pensamiento innovadory participación de todos los integrantes del equipo juegan un papel 
importante. 
 
Presentamos a continuación 5 preguntas y respuestas sobre la identificación de riesgos: 
 
1.- ¿Quién debe participar? 
La identificación de riesgos es un ejercicio en el cual debe participar integrantes claves de 
todas las áreas técnicas involucradas en un proyecto, específicamente: 
• El Sponsor del Proyecto. 
• Gerente / Jefe de Proyecto. 
• Integrantes del equipo. 
• Representantes del cliente o área de negocio solicitante del proyecto. 
• Usuarios finales del producto o sus representantes (no necesariamente es el mismo 
cliente). 
• Expertos técnicos externos al proyecto. 
• Otros sponsors y gerentes de proyectos similares. 
• Otros involucrados en el proyecto. 
• Expertos de la oficina de gestión de proyectos o unidad de gestión de riesgos. 
 
No necesariamente todos los integrantes del equipo deben participar, puede hacerse con 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 16 
integrantes clave, sin embargo, deben existir canales de comunicación para que cualquier 
persona pueda levantar alertas sobre algún riesgo. 
 
Los expertos técnicos poseen conocimiento detallado del producto y sus implicaciones 
técnicas, desempeñando labores de consultoría. Al igual que los expertos de la oficina de 
gestión de proyectos o unidad de gestión de riesgos quienes poseen conocimientos en 
metodología. 
 
2.- ¿Cuándo debe hacerse? 
El primer y mayor esfuerzo de identificación de riesgos debe hacerse durante la fase de 
planificación del mismo, antes de comprometer el cronograma y presupuesto final del 
proyecto. La forma proceder consiste en: 
• Antes de iniciar la identificación de los riesgos, es necesario tener avance en la primera 
versión de la definición de alcance, cronograma, presupuesto, planes de calidad y 
comunicaciones. 
• Luego, se recopilan todos los riesgos identificados durante dicha elaboración y se 
documentan en el registro de riesgos. 
• Cuantificar y desarrollar planes de respuesta para los riesgos identificados. 
• Revisar nuevamente el alcance, cronograma, presupuesto y plan de calidad, para ajustar 
los mismos según los planes de respuesta al riesgo determinados. 
 
Por ejemplo, si se decidió eliminar una actividad riesgosa del alcance, el documento de 
definición de alcance es actualizado, o por ejemplo si se decidió incluir una holgura para 
compensar por un posible retraso en un insumo, esto debe registrarse en el cronograma. 
 
De nada sirve identificar los riesgos si después no se toman acciones en los planes para 
responder a los mismos. 
 
La Oficina de Proyectos de Informática ofrece al público una Plantilla para la Gestión de 
riesgos en la cual se pueden documentar todos los riesgos identificados. 
 
3.- ¿La identificación de riesgos se hace solamente en la fase de planificación? 
 
No, la identificación de riesgos debe ser continua durante todo el proyecto, no concluye con 
la fase de planificación. Una vez comience la ejecución del proyecto, periódicamente deben 
revisarse el registro de riesgos para determinar si los mismos continúan vigentes o si existen 
nuevos riesgos. 
 
Si se identifican nuevos riesgos o algunos cambian de nivel de impacto, deben realizarse 
correcciones a los planes de proyecto en las áreas de alcance, cronograma, presupuesto, 
calidad, comunicaciones, etc. 
 
La figura muestra como la identificación de riesgos se realiza en distintas etapas del proyecto. 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 17 
 
 
Por ejemplo, si al principio del proyecto habíamos reservado cierta holgura para cubrir un 
riesgo y durante la ejecución, para luego determinar que dicho riesgo no ocurrirá (tiene baja 
probabilidad), podríamos eliminar la holgura y terminar antes de la fecha. 
 
Otro ejemplo, si identificamos un nuevo riesgo sobre la calidad del producto, podríamos 
evaluar incluir pruebas adicionales en el plan de calidad, lo cual a su vez supondrían cambios 
en las definiciones de alcance, cronograma y presupuesto. 
 
4.- ¿Cómo influyen la creatividad y el pensamiento innovador en la identificación de 
riesgos? 
 
La creatividad y el pensamiento innovador desempeñan un papel fundamental, el fomentar 
que los Gerentes de Proyectos y miembros del equipo a que realmente se involucren en la 
identificación de riesgos, permitirá un mayor campo sobre el cual realizar análisis y planeación 
de las respuestas. 
 
El Análisis de escenarios y las sesiones de tormenta de ideas (Brainstorming) son aspectos 
importantes, pero lo es más aún el fomentar un ambiente de trabajo en el cual a los integrantes 
del equipo estén abiertos a nuevas ideas y cierto grado de pesimismo. 
 
Es necesario motivar e inclusive premiar a miembros del equipo que sin tapujos planteen 
situaciones riesgosas y muestren interés en identificar todas las áreas en que posibles fallas 
puedan ocurrir. 
 
Cuando de identificación de riesgos se trata, entre más creativo sea, menor expuesto se 
estará a la incertidumbre en el logro de los objetivos. 
 
5.- ¿Cuáles son las herramientas y técnicas a usar en la identificación de los riesgos? 
 
El registro de riesgos 
De entrada, es importante contar con un instrumento que sirva para el registro de los riesgos 
que se van a documentar en el proyecto. Nuestro blog “La Oficina de Proyectos de Informática” 
cuenta con una plantilla. 
 
http://4.bp.blogspot.com/-9ekvhHkMuVc/UIwRmhpBCDI/AAAAAAAAAiw/NnMejauWStc/s1600/Lamina+Identificacion+de+Riesgos.png
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 18 
 
Catalogo de riesgos 
También, es importante contar con un marco de referencia de los riesgos presentes en el 
proyecto que se está ejecutando, para esto, puede solicitarse un “catalogo de riesgos” a la 
Oficina de gestión de proyectos o unidad de gestión de riesgos. Si no se cuenta con estos 
recursos, se puede emplear consultores en gestión de riesgos y consultar a expertos técnicos 
en el área de proyecto. 
 
Un catalogo de riesgos por lo general consiste en documentación de un conjunto de riesgos 
que pueden estar presente en un determinado proyecto, clasificados en categorías como por 
ejemplo económicos, gestión de proyectos, cliente, proveedores, producto, etc. Esta lista de 
riesgos predefinidos puede variar según la industria. 
 
El catalogo de riesgos se puede organizar de forma de lista de chequeo (Checklist) en la cual 
cada riesgo genérico es analizado por el equipo y se determina si está presente o no en el 
proyecto. 
 
Técnicas para identificar los riesgos 
Una vez se cuente con las herramientas, se ejecutan una o varias reuniones con los 
involucrados mencionados en el punto 1, en el cual cada participante va aportando sus 
conocimientos para identificar los riesgos del proyecto. 
 
Entre las técnicas a utilizar destacan: Las sesiones de tormenta de ideas, entrevistas 
individuales o técnica delphi. Bajo esta última, los expertos son consultados de forma 
individual vía correspondencia. 
 
Durante las reuniones, se hace uso de técnicas de diagramación para entender mejor los 
problemas, se revisa el checklist o catalogo de riesgos como base de referencia, y se analizan 
las causas raíz de las situaciones que ocasionan los riesgos. 
 
El análisis de fortalezas ydebilidades de la organización (FODA) y analizar las premisas del 
proyecto pueden ser buenas fuentes de información para identificar los riesgos puede ser. 
 
Por ejemplo, poner como premisa que no ocurrirán retrasos en el procesamiento en aduana 
de cierto material podría ser demasiado optimista, representando un riesgo sobre el comienzo 
a tiempo de una actividad. 
 
También se puede recurrir al juicio de expertos, proporcionado por Sponsors o Gerentes, 
integrantes del equipo (expertos técnicos) que han participado en proyectos similares o 
inclusive consultores externos expertos en la industria. 
 
Conclusión 
 
Para el éxito de la gestión de riesgos es imprescindible que estos sean identificados de forma 
temprana, siendo clave que esto ocurra antes de comprometer con el cliente del producto el 
alcance, fecha de entrega y presupuesto del proyecto. 
 
Una vez identificados, sus planes de respuesta deben ser contemplados en la planificación 
en la forma de cambios de alcance en las actividades, modificación de la forma de realizar el 
trabajo, inclusión de holguras y reservas de presupuesto, así como decisiones de 
incorporación de personal con mayor experticia o subcontrataciones con terceros. 
 
Plantillas Scrum: Hoja de ruta del producto 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 19 
 
 
La hoja de ruta del producto (Agile Product RoadMap) describe como se visiona la evolución 
del producto a lo largo de varias salidas a producción, similar a un plan de producto, ve más 
allá de un proyecto o Release individual, describiendo la ruta que seguirá el producto en los 
próximos 12 meses o mas. 
A diferencia dela lista de producto (Product Backlog) el cual es un documento ideal para 
capturar ideas y requerimientos, la hoja de ruta es para describir como se desarrollará el 
producto en el futuro. 
Se presenta una Plantilla Scrum para la hoja de ruta de producto, en la cual podrás ver una 
hoja de ruta, la cual se divide en flujos de trabajo, a los cuales se les asignan funcionalidades 
y des presenta la línea de tiempo en cuanto a los objetivos para desarrollar y lanzar a 
producción. 
Descripción de la plantilla 
 
La Plantilla Scrum de la Hoja de ruta del producto, abarca los siguientes elementos: 
• Período de tiempo: Son los períodos de tiempo en los cuales se presentará la 
información, por ejemplo meses, trimestres, semestres, etc. 
• Flujos de trabajo: Cada flujo de trabajo es una línea de producción o grupo de trabajo. 
De esta forma cada grupo de trabajo puede desarrollar funcionalidades para el Software con 
recursos independientes de los otros, pudiendo trabajar en paralelo. 
• Funcionalidades: En la lista de producto (Product Backlog) en Scrum pueden 
agruparse los requerimientos similares en funcionalidades, estas son asignadas a cada flujo 
de trabajo, señalando las fechas de comienzo y fin estimadas para desarrollarlas. 
 
 
 
 
 
 
http://www.pmoinformatica.com/2013/11/plantillas-scrum-pila-producto-product.html
https://4.bp.blogspot.com/-YcGTFlT8pS0/WeVZicgaimI/AAAAAAAAFF8/pQ-6i9m0BRML7c8wvnUYdplNy4wCWTizwCLcBGAs/s1600/Plantillas+Scrum+Hoja+de+ruta+de+producto.jpg
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 20 
 
Anexo 
Matriz de Trazabilidad de Requisitos 
Descripción del contenido de la matriz de requisitos 
 
La matriz de trazabilidad de requerimientos del proyecto es el instrumento base para el diseño 
y ejecución de la ingeniería de requisitos. 
 
Aquí describimos el contenido de cada columna de la plantilla de matriz de requisitos e 
información que debes completar en cada una. 
 
• Identificación: Código de identificación de mayor nivel definido para el requisito. Puede 
definirse con números, por ejemplo 001, 002, 003, y así sucesivamente. 
• Sub identificación: Sub código de identificación que puede utilizarse para definir 
requisitos detallados y asociarlos a un requisito padre. De esta forma se define la trazabilidad 
entre requisitos de alto nivel con requisitos más detallados. Puede definirse según el número 
de requisito padre, por ejemplo para el caso de 001 podría definirse el requisito 1.1 y 1.2. 
Pueden también definirse niveles adicionales de detalle de requisito, por ejemplo el requisito 
1.1.1 y 1.1.2 estarían asociados a 1.1. 
• Descripción del requisito: Se proporciona una descripción de que comprende o en qué 
consiste el requisito. La descripción del requisito depende del tipo que sea, por ejemplo 
requisitos del negocio, requisitos de los interesados, requisitos funcionales, requisitos no 
funcionales, requisitos del proyecto o requisitos del producto (solución). 
• Versión: Número de versión del requisito en su estado actual. De esta forma los requisitos 
se pueden ir detallando o modificando en versiones sucesivas. 
• Estado actual: Puede ser solicitado, aprobado, asignado, completado, cancelado, diferido, 
aceptado, entre otros. 
• Última fecha de estado registrado: Fecha en la que se realizó el último cambio de estado 
del requisito. 
• Criterios de aceptación: Lista los criterios de aceptación, una lista de puntos o 
condiciones específicas que deben cumplirse para poder registrar que el requisito ha sido 
satisfecho. 
• Nivel de complejidad: Puede definirse una complejidad de forma cualitativa, por ejemplo 
baja, moderada o alta. Esto dependerá del criterio del evaluador. 
• Necesidad, oportunidades u objetivos de negocio: Vínculo del requisito con la 
estrategia de la organización, listando necesidades específicas que tenga el área de negocio, 
objetivos de la planificación estratégica que busca lograr u oportunidades de negocio o del 
mercado. Esto también se puede vincular con la Gerencia del portafolio al que pertenece el 
proyecto. 
• Objetivos del proyecto: Vínculo del requisito con los objetivos del proyecto. Aquí se 
establece la trazabilidad entre el requisito y los objetivos específicos del proyecto definidos e 
su alcance. 
• Entregables (EDT): Entregables de la estructura desagregada de tarea (EDT) en los 
cuales está inmerso el requisito. Puede especificarse tanto el nombre del elemento de la EDT 
como su código EDT. 
• Diseño del producto: Implicaciones que tiene el requisito desde el punto de vista del 
diseño del producto. Aquí se especifica como el diseño del producto incorpora los 
componentes necesarios para poder satisfacer el requerimiento. 
• Desarrollo del producto: Implicaciones del requisito en el desarrollo del producto. 
Describe como los procedimientos de trabajo, metodología o estándares usados incorporan 
el requisito. Esto aplica principalmente para requisitos que definen la forma de trabajar, 
estándares a cumplir, entre otros. 
Facultad de Ingeniería – UNJu Sistemas de Información 
 
Prof. Adj. Lic. Analia Herrera Cognetta 21 
• Estrategia y escenarios de pruebas: Listado de las estrategias y escenarios de 
pruebas que se contemplarán para validar la aceptación del requisito. Estos se definen a 
partir de los criterios de aceptación. 
• Interesado (Stakeholder) dueño del requisito: Nombre, departamento y cargo del 
interesado (Stakeholder) que originó la solicitud del requerimiento particular. Debe 
corresponder con el que es especificado en el registro de interesados del proyecto. 
• Nivel de prioridad: Según la evaluación de la importancia del requisito para el logrode los objetivos del proyecto, se asigna un nivel de prioridad. Este nivel también puede 
depender del grado de influencia del interesado y estrategias que se estén empleando para 
gestionar la participación de los interesados.

Otros materiales