UNIIVERSIDAD NACIONAL JOSE FAUSTINO SANCHEZ

CARRION
FACULTAD DE INGENIERIA INDUSTRIAL, SISTEMAS E INFORMATICA
ESCUELA DE INGENIERIA DE SISTEMAS

Gestión de Requerimiento

DOCENTE:
ING. FLORES FLORES, Ronald Demetrio

ASIGNATURA:
COMPLEMENTO ESPECIALIZADO

ALUMNO:
RODRÍGUEZ MUÑOZ, Carlos

HUACHO – 2020
 GESTION DE REQUERIMIENTO
1. ¿Qué es gestión de requerimiento?

La gestión de requerimientos es una función obligatoria e ineludible en un proyecto de

desarrollo de sistemas, sea cual sea su naturaleza. Con mayor o menor detalle o
estructuración, pero siempre se hace y es independiente de la experiencia del
responsable.

2. ¿Cuál es la finalidad de la gestión de requerimiento?

 Asegurar que los interesados relevantes tienen la oportunidad de expresar sus

deseos y necesidades.

 Reconciliar los requerimientos múltiples de los interesados para crear un solo

conjunto de objetivos viables.

 Lograr una línea base de requerimientos en consenso con los interesados.

3. Características

 Único: aborda requisito único núcleo.

 Corriente: es actualizado y relevante para las necesidades del negocio.
 Consistente: no entra en conflicto con otros requisitos.
 Comprensible: es claro y sin ambigüedades.
 Verificable: conformidad de los productos diseñados para cumplir con el
requisito puede ser verificada a través de la inspección, demostración o
prueba
 Rastreable: la exigencia puede ser rastreada desde la necesidad de origen, a
través del proceso de entrega.
 Prioridad: su importancia se entiende en relación con otros requisitos.

4. Estructura
La estructuración de requerimientos es el arte de organizarlos de manera coherente. Es
un arte porque esencialmente nada deja de funcionar porque se haga bien o mal, lo
que ocurre es que bien organizado se trabaja menos y el problema se entiende mejor.
5. Clasificación
Los requerimientos se pueden definir de distintas maneras, la primera clasificación que
encontramos se encuentra relacionada con el nivel de descripción con la que cuentan
los requerimientos. Dentro de este tipo de clasificación encontramos los siguientes:

REQUERIMIENTOS DE USUARIO: Son declaraciones, en lenguaje natural y en

diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.
REQUERIMIENTOS DE SISTEMA: Estos requerimientos establecen con detalle las
funciones, servicios y restricciones operativas del sistema.

La siguiente clasificación observaremos es la que se da a los requerimientos del

sistema, la cual se encuentra dividida en base a lo que se va a describir, las
clasificaciones son las siguientes:

o REQUERIMIENTOS FUNCIONALES: Son declaraciones de los servicios que debe

proporcionar el sistema, de la manera en que éste debe reaccionar a entradas
particulares. O también pueden declarar explícitamente lo que el sistema no debe
hacer.
o REQUERIMIENTOS NO FUNCIONALES: Son restricciones de los servicios o
funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el
proceso de desarrollo y estándares. Dentro de estos requerimientos encontramos
todo lo referente a fiabilidad, el tiempo de respuesta y la capacidad de
almacenamiento.

6. Tareas principales
 Recolección: Recolección y documentación de requisitos es una actividad de
comunicación iterativa entre clientes, gerentes y practicantes (stakeholders del
proyecto), para descubrir, definir, refinar y registrar una representación precisa de
los requisitos del producto. Varios métodos son utilizados para la recolección de
requisitos. Algunos análisis iniciales como es la agrupación categorización,
priorización son desarrollados durante esta actividad.

 Documentación: Después que los requisitos han sido recolectados, hay que
analizarlos a detalle y documentarlos en una especificación de requisitos. El
resultado de la especificación de requisitos y de cualquier especificación de
requisitos de componentes hardware/software derivado sirve como registro de
convenio con el cliente y compromiso con el proveedor. Estas especificaciones son
rastreadas utilizando una matriz de trazabilidad de requerimientos y son sujetos a
verificación y gestión de cambio a través del ciclo de vida del producto.

 Verificación: Una vez que la especificación de requisitos ha sido desarrollada, los

requisitos son verificados. La verificación de requisitos es un proceso para
asegurar que la especificación de requisito del producto es una representación
exacta de las necesidades del cliente. Este proceso también asegura que los
requisitos sean trazados y verificados a través de varias fases del ciclo de vida;
particularmente en el diseño, implementación y pruebas. Los requisitos deben ser
trazados desde fuentes externas, tales como los clientes, para derivar requisitos
del nivel del sistema, para especificar requisitos del producto hardware/software.
Además, todos estos requerimientos deben ser trazados al diseño,
implementación y pruebas para asegurarse que los requerimientos han sido
satisfechos.
  Gestión de Cambios: Gestión de cambios es un proceso formal para identificar,
evaluar, trazar y reportar cambios propuestos y aprobados a la especificación del
producto. Como el proyecto va evolucionando, los requerimientos pueden
cambiar o expandirse para ajustar algunas modificaciones en el alcance o diseño
del proyecto. Un proceso de gestión de cambios proporciona un rastreo completo
y preciso de todos los cambios que son pertinentes al proyecto.

7. Responsables de la Gestión de Requerimiento

En principio, el responsable de la gestión de los requisitos de un proyecto es el Director
de Proyecto que debe contemplar su aplicación desde la etapa de inicio, en la
formulación del alcance y, posteriormente en la de planificación, determinando el
modo de abordarlos en la ejecución. Tareas sucesivas de monitorización y seguimiento
permitirán comprobar si su cumplimiento se lleva a cabo puntualmente y en
condiciones óptimas. Llegado el momento de cierre, en la etapa de finalización de
proyecto, será necesario incluir la evaluación de cumplimiento de requisitos en el
proceso de valoración general del proyecto; aunque siempre es recomendable medir
su progreso al final de cada etapa o cada vez que se completa un entregable, ya que
sólo de esta forma se está en disposición de tomar acciones, caso de ser necesario,
evitando consecuencias de mayor calado a medida que el progreso del proyecto sigue
su curso. Cabe especificar que, dada la distribución de roles y responsabilidades que
tiene lugar en un proyecto, puede suceder que el responsable de la aplicación de un
requisito o de su satisfacción sea en primera instancia la persona (o grupo de personas)
a la que se ha asignado esa tarea. No obstante, el responsable último será siempre el
project manager por serlo del proyecto en conjunto y su evolución y por su condición
de interlocutor válido de cara al cliente, otro aspecto a tener en cuenta.

8. Reglas generales
En la gestión de requerimientos como en el resto de las tareas en un proceso de
ingeniería de software, que generalmente es más complejo de lo que uno quisiera,
aplican una serie de reglas son útiles a la hora de tomar una decisión de qué hacer y
que no hacer.

ORO: Mientras más simple mejor. Esta es como una moneda de oro, que tiene dos
caras: por una cara manejar los requerimientos de la manera más sencilla posible hará
más fácil la administración de los requerimientos. Por la otra cara, si no se recoge toda
la información necesaria para la administración, la información que en las manos del
responsable del proyecto es útil, pierde su aplicación al estar incompleta. Es decir,
simple no es incompleta.

PLATA: La redundancia de información es siempre un problema. Un análisis no

cuidadoso puede caer fácilmente en redundancia de información, colocando
requerimientos del sistema o características de la solución como necesidades de la
organización, o bien repitiendo información para rellenar los niveles de información
comprometidos. El análisis de sistemas es, de por sí, un adelanto de la programación
del sistema, en el que cada componente tiene una misión, y los componentes no está
para construirlos una y otra vez, por el contrario se construyen una vez, se colocan en
el lugar adecuado y se utilizan las veces que sean necesaria, esto es, los requerimientos
se escriben una vez y se escriben de manera simple, se les da la clasificación adecuada,
y se trazan las veces necesarias.
 BRONCE: Los requerimientos no desaparecen porque no se tengan en cuenta. En física,
la ley de la conservación de la materia enuncia: "la materia no se crea ni se destruye,
se transforma", en ingeniería de software el equivalente sería la ley de la gestión de los
requerimientos: "los requerimientos no se acomodan o se desaparecen, se
descubren". Una solución informática a un problema de negocio tiene una cantidad de
requerimientos intrínsecos que provienen del negocio. El no tomarlos en cuenta no
significa que el sistema no los necesite, sino que no han sido tomados en cuenta y que,
a la larga, los mismos han de ser desarrollados. La diferencia está en el momento en
que son descubiertos y el estado de ánimo con el que terminará la parte que deba
pagar la diferencia (bien sea el proveedor o el cliente). No tomar en cuenta los
requerimientos desde un inicio, está más que probado, que es más costoso que hacer
un buen análisis que los contemple. El no encontrarlos supone, en el mejor de los
casos, inexperiencia de la parte que hace el análisis, y en el peor, mala intención en el
descubrimiento de los mismos. Para la parte que hace el análisis, en realidad, ninguno
de los dos escenarios son buenos.

9. Gestión del cambio (Trazabilidad)

La trazabilidad en los requerimientos es un aspecto fundamental de la administración
de los requerimientos porque ayuda a:
1) Asegurar que el sistema se enfoque en resolver las necesidades del negocio si hacer
goldplating.
2) Asegurar que todas las necesidades estén cubiertas por la solución planteada.
3) Gestionar los requerimientos adecuadamente luego que terminó el proceso de
análisis.
4) Comprender el impacto de un cambio en los requerimientos, dando respuestas
rápidas y precisas a una solicitud.
5) Evitar la redundancia de información.
6) Distribuir el trabajo entre el equipo de proyecto de manera coherente.
 10. Análisis de impacto
El análisis de impacto de la trazabilidad captura los vínculos entre requisitos,
especificaciones, elementos de diseño y pruebas, analizando sus relaciones para
determinar el alcance de un cambio iniciador. La determinación manual de lo que se
verá afectado por un cambio puede llevar mucho tiempo en proyectos complejos, que
es donde entra en juego el software de gestión de requisitos.

11. Describa la siguiente imagen

IDENTIFICACIÓN DE NECESIDADES CON EL CLIENTE

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico
que para recabarlos haya que obtener la información de primera mano. Esto es, mediante
entrevistas con el cliente u obteniendo la documentación que describa la manera que el
cliente desea como funcione el sistema de software. Las necesidades y / o requerimientos
del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es
necesario tener archivada una copia de la documentación original del cliente, así como
cada revisión o cambio que se haga a esta documentación.

Técnicas generales para la identificación de requerimientos

Las técnicas agrupadas como generales son las que permiten investigar aspectos generales
para posteriormente ser especificados con un mayor detalle con el apoyo de técnicas más
específicas. Estas técnicas son más abiertas y requieren ser adecuadamente orientadas
para cubrir la información que se requiere capturar, es importante que para sacar el mayor
provecho de estas técnicas se debe tener un dialogo lo más abierto posible entre las
organizaciones de desarrollo de software y las empresas cliente.
 Técnicas específicas para la identificación de requerimientos

Las técnicas agrupadas como especificas son las que permiten complementar las técnicas
generales, para así obtener mayor detalle y eliminar ambigüedad en la información inicial.

 Observación
Esta técnica permite obtener información directa sobre la forma en que se realizan las
actividades. Es una técnica que sirve para revisar que no existen omisiones o
interpretaciones erróneas sobre el proceso que se realiza. Hay que tener en cuenta que se
debe utilizar si el cliente lo permite y si el proyecto así lo amerita.

 Escenarios
Esta técnica permite conocer el comportamiento del producto ante determinados eventos
considerando los datos, acciones y excepciones que se pueden presentar. El análisis de
casos de uso es un ejemplo de aplicación de esta técnica.

Definición de Requisitos
Para realizar con éxito la definición de los requerimientos es importante conseguir que los
requerimientos sean claramente definidos para minimizar la ambigüedad de los
requerimientos, para esto es importante tener en cuenta lo siguiente:

 Definir los requerimientos teniendo en cuenta la información identificada con la

perspectiva del usuario

 Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen

material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez
que un requisito ha sido especificado satisfactoriamente para un producto y que el
producto ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá
ser utilizado las veces que se desee teniendo en cuenta los derechos de autor.

 Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría

de los proyectos se observa que la documentación de los requerimientos puede
parecer una tarea tediosa, pero es la única manera de asegurar que la esencia de los
requisitos ha sido capturada correctamente, y que esto pueda ser probado

GESTIÓN DE CAMBIOS
La gestión de cambio en los proyectos debe ser una coordinación planificada de las
actividades que conlleve el logro de los objetivos o propósitos comunes a través de una
comunicación clara y eficiente.

GESTIÓN DE REQUERIMIENTO
Para que la gestión de los requerimientos sea realmente aplicable al cliente en pro de la
satisfacción de las necesidades y control del proyecto en general, se debe cumplir con las
siguientes acciones:
 Matrices de Trazabilidad

o Matriz de relación de documentos

La siguiente Matriz nos muestra cuales son las relaciones de documentación de cada
requisito su clasificación si es de negocio, usuario o sistema y si es funciona o no funcional,
su respectivo caso de uso, sus casos de prueba asociados, la dependencia con otros
requerimientos y las peticiones de cambio en caso que las tenga.

o Matriz de valoración y aprobación de los requisitos

La siguiente matriz de trazabilidad es la que nos permite valorar si el requisito cumple con
todas las etapas llevadas a cabo en la metodología, en caso que todos los criterios se
cumplan se dará por cerrado y aprobado el requisito.

 Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambios que se van
presentando, en esta matriz podremos registrar el número de control de cambio que se
tiene asignado, la referencia a la documentación de dicho control, quien aprobó el control,
quien lo llevo a cabo o quien lo está realizando, por quien fue revisado en caso que ya se
encuentre revisado, su porcentaje de ejecución hasta llegar al 100%, el o los requisitos
afectados y una descripción breve del control de cambios.

Esta matriz nos permitirá llevar un control detallado de los controles de cambios solicitados
y su estado actual.

FORMATOS DE LA METODOLOGÍA
Los formatos utilizados en las plantillas se presentan como una herramienta de apoyo y
soporte a las actividades sugeridas en la presente metodología.
Por lo tanto, cada uno de los formatos a utilizar presenta las especificaciones
correspondientes para su diligenciamiento.
A continuación, se encuentran cada uno de los formatos recomendados para utilizar en los
capítulos que hacen parte de esta metodología:

Capitulo Formato Objetivo

Cap 1 FMR_001_Identificacion de Presentar una descripción de lo
Necesidades que se requiere desde la
perspectiva del cliente para
resolver la necesidad u
oportunidad de mejora
identificada.
El presente documento será
trabajado de la mano del
cliente.
Cap 2 FMR_002_Entrevista Sugerir preguntas que
permitan detallar el
requerimiento.
Cap 3 FMR_003_Matrices_Trazabilidad Presentar matrices de
trazabilidad (Relación de
documentación, Revisión de
Pares, Registro de Controles de
Cambio)
Cap 4 FMR_004.1_00X_Especificacion Especificar detalladamente la
Funcional funcionalidad (requerimientos
 FMR_004.2_00X_Caso de Uso funcionales y no funcionales)
FMR_004.3_00X_Especificacion de los componentes del
de Diagramas sistema y sus interacciones
Cap 5 FMR_005.1_Planeación Prueba Presentar la estrategia,
de requerimiento alcance, estimación de
tiempos, de la prueba de
requerimiento.
FMR_005.2_Diseño de Casos de Identificar los posibles casos de
Prueba prueba del requerimiento
FMR_005.3_Ejecucion de Casos Presentar resultado de
de Prueba ejecución de los casos
FMR_005.4_Informe final prueba Presentar informe de cierre
con los aspectos más
relevantes de la ejecución
Cap 6 FMR_006_Control de cambios Describir la situación de cambio
solicitada por el cliente.