Unidad 2
Gestión de
Requerimientos
IIngeniería de Requerimientos
(continuidad)
Página 1 de 21
Introducción .......................................................................................................................................2
1. Requerimientos de un proyecto .....................................................................................................3
1.1. Levantamiento de requerimientos ..........................................................................................3
1.2. Minuta Kick Off ........................................................................................................................4
1.3 Acta de constitución .................................................................................................................6
2. Adquisición y análisis de los requerimientos ..................................................................................8
3. Validación y administración de los requerimientos......................................................................17
Conclusiones ....................................................................................................................................20
Referencias bibliográficas ................................................................................................................21
Página 2 de 21
Introducción
Los requerimientos son los elementos
fundamentales para desarrollar un proyecto, y según
PMBOK®(SaraClip, 2017) (Project Management Body
of Knoledgement) son definidos como una condición
o capacidad que debe tener un producto, servicio o
componente para satisfacer un contrato, estándar,
especificación u otros documentos formalmente
establecidos.
Los requerimientos se obtienen de un levantamiento o captura de información con el
cliente o interesados en el desarrollo del sistema, dado que poseen una problemática en la
organización y el equipo de desarrollo, hará gestiones para dar solución.
Para efectuar este levantamiento se utilizan diversas técnicas de captura, entre ellas, se
considera la entrevista, cuestionarios, observación, lluvia de ideas, entre otras. Por tanto,
una vez obtenidos los datos, se registran en la minuta Kick Off (reunión de inicio de un
proyecto), en la cual se deja la evidencia de este proceso. Posteriormente, en el Acta de
Constitución, se declara formalmente lo analizado, como las necesidades y expectativas de
las partes interesadas. Además, para ser aprobada, requiere que todas las partes
involucradas en el desarrollo del proyecto estén de acuerdo.
Los requerimientos son clasificados como funcionales y no funcionales, donde los primeros
corresponden a lo que hace el sistema y los segundos, a cómo lo hace el sistema.
Los funcionales se pueden captar en base a dos metodologías siendo estas tradicional o ágil.
En ambos casos, debe consignar fases para completar dicho proceso.
Por su parte, los no funcionales, enfocados en cómo lo hace el sistema, poseen una
clasificación de producto, organizacional y externo.
Ambos requerimientos facilitan que el desarrollo de un proyecto sea exitoso, considerando
el correcto levantamiento de información, para avanzar según la metodología seleccionada,
y de esta forma dar respuesta satisfactoria al cliente u organización, una vez validados con
los interesados.
Finalmente, son registrados en una planilla de clasificación de requerimientos, para definir
el estándar de trabajo con ellos.
Página 3 de 21
1. Requerimientos de un proyecto
En la unidad anterior aprendimos los conceptos asociados a un proyecto, sus objetivos y los
actores que intervienen en él.
En esta unidad, conoceremos cómo realizar el levantamiento de requerimientos para luego
analizar, clasificar y validarlos, para dar respuesta a la problemática existente presentada
por el cliente u organización, dejando esta evidencia registrada en diferentes documentos.
1.1. Levantamiento de requerimientos
Para iniciar este proceso se debe definir a los actores que serán los entrevistados, ellos son
los que proporcionarán la información relevante sobre la problemática actual de la
organización y que requieren resolver. Entre ellos se consideran:
Stakeholders Aquellos que tienen interés en el desarrollo del proyecto y pueden ser
inversionistas, accionistas o patrocinadores.
Usuarios claves Son quienes proporcionan información directa y efectiva, dado que son
los involucrados en el proyecto.
Entonces, para obtener la información requerida en el desarrollo del proyecto, se puede
aplicar:
La entrevista, la cual es de gran utilidad, dado que entrega información
cualitativa como son las opiniones o descripciones subjetivas. Se necesita de
un par de horas para llevarla a cabo y es ideal hacerlo con preguntas abiertas.
Cuestionarios, orientado a un grupo numeroso de entrevistados.
Observación, esta técnica verifica si realmente lo descrito por los
entrevistados se realiza efectivamente.
De igual manera, existen otras técnicas como la lluvia de ideas y análisis de documentación,
entre otras.
Página 4 de 21
PREGUNTA
¿A quién o quiénes se deben entrevistar para obtener información
relevante sobre la problemática de la organización?
Se entrevistan a los interesados en desarrollar un sistema para beneficiarlos con la
automatización, entre ellos, se consideran:
- Stakeholders: son aquellos que tienen interés en el desarrollo del proyecto y estos
pueden ser inversionistas, accionistas o patrocinadores.
- Usuarios claves que proporcionan información directa y efectiva, dado que son los
involucrados en el proyecto.
1.2. Minuta Kick Off
La reunión Kick Off es la reunión inicial en la cual se reúnen a todos los representantes de
la organización o cliente con los representantes de la empresa responsable del desarrollo
del proyecto, para revisar las directrices del proyecto y determinar los objetivos, establecer
el trabajo a desarrollar y los acuerdos de gestión, estructurar la forma de comunicación,
validar los plazos y recursos que estarán disponibles para dicho evento.
En esta reunión se discuten los requerimientos para generar una minuta (documento) que
refleje los requerimientos iniciales del proyecto.
¿Qué información se registrará en la minuta Kick Off?
Es la información recolectada sobre la problemática que tiene la organización y las técnicas
que se aplicarán para realizar el levantamiento de los requisitos.
¿Cuál es el objetivo?
Establecer las directrices para dar inicio con el desarrollo del proyecto, determinar los
objetivos y alcance y plazos de entregas.
¿Qué contiene la minuta Kickoff?
Kick Off?
Página 5 de 21
Parte 1 Detalles de fecha, lugar y tipo de entrevista, quiénes participan y su función
dentro de la organización y datos de la reunión, como el tema a tratar.
Parte 2 Los requerimientos generales del proyecto.
Parte 3 Nombre de los actores del negocio y del proyecto y su rol o cargo en la
organización.
Parte 4 Acuerdos del proyecto.
Parte 5 Limitaciones del proyecto.
Parte 6 Técnicas que se utilizan para capturar los requerimientos y el nombre del actor
que fue entrevistado u observado.
Página 6 de 21
Fuente: [Link]
PREGUNTA
¿Cuál es el objetivo de la minuta KO?
Es establecer las directrices para dar inicio con el desarrollo del proyecto, determinar los
objetivos, alcance y plazos de entregas.
1.3 Acta de constitución
Es un documento formal en el cual que se registra la aprobación del proyecto, además de
determinada información de este como alcance, objetivos y participantes.
Página 7 de 21
Características:
Kick Off?
● Es un documento que registra los requisitos capturados, estableciendo las
necesidades y expectativas de las partes interesadas, y gestionando para la
satisfacción de estas.
● Para ser aprobada, requiere que todas las partes involucradas en el desarrollo del
proyecto estén de acuerdo.
● Se define al Project Manager.
● Se definen los roles y responsabilidades.
¿Qué partes componen este documento?
Las partes de composición del acta de constitución son:
● Información del proyecto: Está compuesta de los datos, patrocinadores, gerente de
proyecto, niveles de autoridad, lista de interesados, cronograma de hitos principales
y presupuesto estimado.
● Descripción del proyecto: Consiste en los objetivos del negocio, justificación del
proyecto-contexto, problema-necesidad.
● Descripción del producto, se compone de la solución propuesta, objetivos del
proyecto y objetivos de desarrollo, entregables.
● Descripción del sistema donde se detallan los requerimientos de alto nivel, premisas
y restricciones, riesgos iniciales de alto nivel, especificaciones técnicas de las
herramientas de desarrollo, tipo de hardware, tipo de interfaz de software y tipo de
interfaz de usuario.
● Requisitos de aprobación del proyecto.
● Aprobaciones y control de cambios.
¿Quién redacta este documento?
El Acta de Constitución es creada por el cliente o gerente o líder del proyecto.
La metodología PMI en la guía del PMBOK de su sexta edición, menciona los puntos
relevantes que incluye el Acta de Constitución de un Proyecto.
Página 8 de 21
Acta de Constitución del Proyecto
Fuente: [Link]
PREGUNTA
¿Por qué se dice que el acta de constitución es la formalidad de los
requerimientos?
Porque es un documento que registra los requisitos capturados, estableciendo las necesidades y
expectativas de las partes interesadas y gestionando para la satisfacción de estas. Además, para
ser aprobada, requiere que todas las partes involucradas en el desarrollo del proyecto estén de
acuerdo. Además, en este documento se define al líder del proyecto.
2. Adquisición y análisis de los requerimientos
Una vez realizado el levantamiento de requerimientos,
es de relevancia chequearlos con todos los interesados
del proyecto, para luego determinar su clasificación, la
cual corresponde a:
• Requerimientos funcionales.
• Requerimientos no funcionales.
Página 9 de 21
Definición de los requerimientos
ENLACE WEB
Recurso complementario/Visita este enlace
Te invitamos a ver el siguiente video en el cual se aborda el tema de
Desarrollo de Sistemas Web y Aplicaciones Móviles desde la
perspectiva de la Definición de los Requerimientos (para acceder
pulsa sobre el ícono a la izquierda).
A. Requerimiento funcional:
Corresponde a la funcionalidad que proporciona el sistema computacional para ser utilizado
por el usuario, es decir, describe las capacidades del producto.
Es lo que hace el sistema, entre ellas se refiere a las acciones y comportamientos con los
cuales el usuario interactúa con el producto.
El requerimiento funcional se escribe como RF, además se asigna un número correlativo.
Ejemplo:
RF1: “El sistema debe enviar una notificación por e-mail al jefe de ventas cuando estas
excedan la meta establecida mensualmente”.
RF2: “El sistema debe almacenar las llamadas telefónicas realizadas por un usuario en
particular”.
RF3: “El sistema debe registrar la geolocalización de pasajero cuando este ingrese al
hotel”.
Los requerimientos funcionales, se clasifican en:
RF del Es el usuario quien explota funcionalmente el sistema, a través de diversas
usuario: interfaces gráficas.
Ejemplo: Registro de ventas.
RF del Se refieren a las funcionalidades que debe cumplir el sistema, considerando los
Sistema: procesos internos que se ejecutan dando respuesta a una operación.
Ejemplo: Obtener el resultado calculando la multiplicación de un número.
Página 10 de 21
En resumen, los requerimientos funcionales son aquellos que permiten expresar las
características funcionales que debe tener y realizar la solución propuesta, con la finalidad
de dar satisfacción al cliente u organización.
¿Por qué son importantes los requerimientos funcionales?
En un alto porcentaje se define que es complejo determinar estos requerimientos, dado
que el cliente y/o usuarios en ocasiones no expresan claramente la problemática real de la
organización, por tanto, la solicitud al proveedor no cumple con lo que realmente se desea.
Entre los problemas detectados se determinan requerimientos ambiguos, generando
dificultad de interpretación o solicitando acciones que posteriormente no son validadas por
el mismo cliente o interesado en el proyecto.
Para estos casos, se sugiere utilizar metodologías de gestión para:
● Solicitar mayor información cuando esta sea ambigua.
● Solicitar validar los requerimientos declarados.
● Solicitar reuniones ante eventualidad de modificar un requerimiento.
Ejemplos
• Utilizando metodología tradicional: Cascada
Fuente: [Link]
desarrollo/4538221-en-que-consiste-el-modelo-en-cascada
Esta metodología permite regirse por etapas o fases, como son:
Página 11 de 21
Entre sus características, se mencionan las reuniones con interesados para realizar la
captura de los requerimientos, donde:
● Se aplican diversas técnicas de captura para obtener la información.
● Se registran los datos necesarios en documentos formales para definir lo requerido.
● Los cambios posteriores a lo establecido se declaran en un documento de cambio.
Utilizando metodología ágil: Scrum
Bajo esta metodología se establece un enfoque más flexible, dado que se basa en
iteraciones cortas y satisfaciendo las necesidades del cliente.
Página 12 de 21
Por ejemplo, el Product Owner, es:
B. Requerimiento no funcional:
Son aquellos requerimientos que hacen la función contraria a los requerimientos
funcionales, es decir, a las propiedades emergentes como la fiabilidad, la respuesta en el
tiempo y la capacidad de almacenamiento. Además, están relacionados con las
características de calidad del sistema.
Propiedades que debe tener un producto.
● Atributos de calidad.
● Restricciones de diseño e implementación.
● Interfaces externas.
Es “CÓMO” lo hace el sistema y se deben documentar en términos cuantificables. Ejemplos:
RNF1: “El sistema debe operar en los siguientes sistemas operativos: Linux, Android
e iOS 10”.
RNF2: “La capacidad de búsqueda del sistema de inventarios debe soportar hasta 200
usuarios concurrentes durante horario de trabajo diario”.
RNF3: “El tiempo de respuesta para mostrar los resultados de una operación renta no
debe superar los 6 segundos”.
Página 13 de 21
Características
Establecen las Surgen de las Son restricciones Incluyen
restricciones del necesidades del de los servicios o restricciones de
sistema y los usuario/cliente funciones tiempo, sobre el
respectivos debido a ofrecidos por el proceso de
atributos de restricciones de sistema. desarrollo y
calidad. presupuesto, estándares.
políticas de la
organización,
interoperabilidad,
etc.
Fuente: [Link]
funcionales-y-no-funcionales
Página 14 de 21
Clasificación:
Requerimientos
no funcionales
Producto Organizacionales Externos
Usabilidad Entorno Regulatorios
Eficiencia Organizacionales Éticos
Dependibilidad Desarrollo Legislativos
Seguridad
Ian Sommerville. Software Engineering. 9a Edición
Fuente: [Link]
Página 15 de 21
Definición por clasificación:
Producto Corresponden a las límites o restricciones sobre el comportamiento del
sistema. Es lo que pueden hacer los diseñadores e ingenieros de
software.
Organizacionales Son en base a las políticas y procedimientos de la organización,
considerándose los estándares de procesos o requerimientos de
implementación.
Externos Son las limitaciones de tipo económica, interacción del sistema de
inter-operar con otros sistemas, requerimientos regulatorios en
diversas áreas de la industria, protección de datos, aspectos legales,
entre ellas certificaciones.
Ejemplos por clasificación:
I. RNF de Producto (Informática, 2015):
Usabilidad Esfuerzo que necesita hacer un usuario para aprender, usar, ingresar
datos e interpretar los resultados obtenidos de un software de
aplicación.
Eficiencia Desempeño en cuanto a tiempo de respuesta, número de
operaciones por segundo, consumo de recursos de memoria,
procesador, espacio en disco o red.
Disponibilidad Disposición del sistema para prestar servicio correctamente.
Confiabilidad Continuidad del servicio prestado por el sistema
Seguridad industrial Ausencia de consecuencias catastróficas para el usuario o el
ambiente
Integridad Ausencia de alteraciones inadecuadas al sistema.
Mantenibilidad Posibilidad de realizar modificaciones o reparaciones a un proceso
sin afectar la continuidad del servicio.
Seguridad Son las capacidades funcionales o no funcionales que tiene un
sistema para cumplir atributos en el área de seguridad de tecnología
de información. Ejemplo, seguridad de datos, autenticidad de la
información.
Fuente: [Link]
Página 16 de 21
II. RNF Organizacionales (Informática, 2015)
Entorno Corresponde al ambiente operativo en el que se debe desenvolver el
sistema.
Operacionales Se refiere a los procedimientos operativos que describen cómo será usado
el sistema dentro del contexto de la organización.
Desarrollo Considera lo que se utilizará como los lenguajes de programación,
estándares de codificación, patrones y anti patrones de diseño y
programación, diversas herramientas para la gestión de desarrollo de
software, entornos de desarrollo de software, de pruebas de software, y
otros.
Fuente: [Link]
III. RNF Externos
Regulatorios Se refieren a las Leyes y reglamentos que establecen qué y cómo debe
hacer el sistema. Si se trata de un nuevo módulo o nueva funcionalidad
debe basarse en una regulación.
Éticos La finalidad es dar cumplimiento a las expectativas del cliente, en forma
clara, precisa y concreta.
Legislativos Todos los requerimientos desarrollados en el sistema y que son
solicitados por el cliente, deben cumplir con las normas de acuerdo con
la ley.
Ejemplo: El área de contabilidad debe regirse en base a las normas
definidas como organismo legal.
Según los siguientes requerimientos, indique a qué tipo
PREGUNTA
corresponde, si es RF o RNF.
1. ___ Autenticar usuario al iniciar sesión
2. ___ Los colores de la página web deben ser los institucionales
3. ___ Calcular el monto de pago de la habitación
automáticamente
1. RF, se basa en lo que hace.
2. RNF, se basa en cómo lo va a hacer.
3. RF, se basa en lo que hace.
Página 17 de 21
3. Validación y administración de los requerimientos
Es importante considerar la documentación dentro de
un proyecto, dado que facilita la comprensión de los
requerimientos de este.
Los requerimientos se registran en la planilla de
clasificación de requerimientos, considerando los
siguientes ítems:
Número de Número correlativo al requerimiento.
identificación:
Nombre del Corresponde al nombre que identifica al requerimiento.
requerimiento:
Tipo de Que sea funcional o no funcional.
requerimiento:
Actor relacionado: El actor que interviene en este requerimiento.
Descripción breve Breve descripción de qué trata el requerimiento.
del requerimiento:
Estado: Se consideran los siguientes estados, solicitado, aprobado,
asignado, completado, cancelado, diferido, aceptado.
El documentar las fases de un proyecto permite registrar los elementos que intervienen y
el paso a paso que se debe seguir para concretar el desarrollo de cada proceso, eliminando
inconsistencias y ambigüedades en el proyecto. Además, permite generar un conocimiento
del proyecto para aquellos actores que se incorporen en etapas posteriores, mostrando los
aspectos técnicos que se deben ejecutar.
Página 18 de 21
Elaborar un proyecto con la correspondiente documentación, genera confianza en el equipo
de desarrollo y en los interesados, mostrando un trabajo responsable en base a normas,
ética profesional y las buenas prácticas.
En esta fase se documentan los requerimientos acordados con el cliente, en un nivel
apropiado de detalle.
Verificación de requerimientos
Se refiere al proceso que se concentra en la revisión de los requerimientos obtenidos.
Generalmente, se aplica un checklist para su verificación, esto permite encontrar y eliminar
discrepancias entre los requerimientos y la ejecución del software.
Aceptación de requerimientos
Este proceso es muy relevante a la hora de realizar el compromiso formal con los
interesados del proyecto, dado que se da inicio a la revisión de cada requerimiento,
considerando el detalle y su justificación, por lo que una vez revisado, analizado y
comprendido la funcionalidad de cada uno de ellos, se solicita al cliente o representante de
la empresa u organización a dar su consentimiento de acuerdo a lo revisado, para aceptar
y paso siguiente aprobar, para continuar con el proyecto.
La formalidad de este compromiso consiste en firmar un documento físico o
electrónicamente, consignando que las partes están totalmente de acuerdo, para iniciar
con las siguientes fases del proyecto.
Página 19 de 21
PREGUNTA
¿Por qué es necesario firmar la documentación una vez que se han
realizado los acuerdos entre las partes involucradas de un
proyecto?
Es relevante firmar la documentación, dado que ello acredita que todos están de acuerdo en
base a los pasos correctos que se ejecutaron para dejar en ella lo acordado.
Reflexión: ¿Por qué crees que es relevante la clasificación de los requerimientos para
desarrollar un proyecto de sistema?
Lectura Obligatoria
LECTURA
Sommerville, Ian. (2005). Ingeniería de Software. Unidad 2: Parte II.
Requerimientos.
7. Procesos de la Ingeniería de requerimientos. Página 129 – 150.
Página 20 de 21
Conclusiones
En esta unidad se entregan los conceptos elementales sobre los requerimientos y la técnica
aplicada para lograr su captura. Estos requerimientos son levantados a través de la
necesidad de un cliente u organización.
Estos requerimientos son evidenciados en documentación formal, siendo inicialmente la
minuta KickOff la que registra este proceso de levantamiento de información,
determinando actividades como fecha, lugar y tipo de entrevista, quienes participan y su
función dentro de la organización y datos de la reunión como el tema a tratar, los
requerimientos generales del proyecto, el nombre de los actores del negocio y del proyecto
y su rol o cargo en la organización, los acuerdos del proyecto, las limitaciones del proyecto
y las técnicas que se utilizan para capturar los requerimientos y el nombre del actor al cual
fue entrevistado u observado.
Luego, estos requerimientos son clasificados en requerimientos funcionales o
requerimientos no funcionales, para finalmente quedar formalmente en el acta de
constitución, siendo de mutuo acuerdo con los interesados del proyecto firmar
considerando respectivamente los siguientes aspectos:
● Información del proyecto.
● Descripción del proyecto.
● Descripción del producto.
● Descripción del sistema.
● Requisitos de aprobación del proyecto.
● Aprobaciones y control de cambios.
Finalmente, la clasificación de estos requerimientos quedará registrada en la “Planilla de
requerimientos”.
Por tanto, es importante destacar que los requerimientos y la documentación cumplen un
rol fundamental en la vida del desarrollo de un proyecto, dado que permiten registrar
evidencia del levantamiento de información y que los procesos se ejecutan en virtud de lo
estimado para el éxito de la gestión.
Página 21 de 21
Referencias bibliográficas
• Campderrich Falgueras, B. (2013). Ingeniería del software. Recuperado de:
[Link] 56294
• González Marcos, A., Alba Elías, F. y Ordieres Meré, J. (2014). Ingeniería de
proyectos. [Link] 43933
• Pressman, R., (2002). Ingeniería de Software, un enfoque práctico. Mc Graw Hill.
Madrid, Es.
• Sommerville, I. (2011). Ingeniería de software. Recuperado de:
[Link]
Este material fue desarrollado por la docente Marcela Ulloa para la Universidad Mayor y
ha sido diseñado para su lectura en formato digital.
Última actualización marzo, 2023.