1

RESUMEN

TÉCNICO SUPERIOR UNIVERSITARIO

METODOLOGIAS Y MODELADO DE DESARROLLO DE

SOFTWARE

Presenta:

Ramírez Fortanel José Cruz

Romero Rivera Andrey

Profesor:

MARIBEL TREJO RESENDIZ

SAN JUAN DEL RÍO, QRO.

ENERO DE 2023
 2

Índice
I. 4.1 Requerimientos funcionales y no funcionales 3
II. 4.2 El documento de requerimientos de software. 6
III. 4.3 Especificación de requerimientos. 7
IV. 4.4 Procesos de ingeniería de requerimientos 11
V. 4.5 Adquisición y análisis de requerimientos. 12
VI. 4.6 Validación de requerimientos 20
VII. 4.7 Administración de requerimientos. 22
 3

Resumen capítulo 4 libro ingeniería de software

Ingeniería de
Requerimientos

I. 4.1 Requerimientos funcionales y no funcionales

Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer: el
servicio que ofrece y las restricciones en su operación, reflejan las necesidades como sería
controlar un dispositivo, colocar un pedido o llegar a buscar información.

El término “requerimiento” no se usa de manera continua en la industria del software. En

algunos casos, un requerimiento es simplemente un enunciado abstracto de alto nivel, en un
servicio que debe proporcionar
un sistema.
 4

Requerimientos funcionales

Estos varían con requerimientos generales y lo que hace el sistema, reflejan las maneras
locales las formas de trabajar o de los sistemas existentes. A veces los requerimientos dependen
del software que se está desarrollando o lo que esperan los usuarios del software .
Define lo que el sistema debe hacer para satisfacer las necesidades o expectativas del
usuario.

Requerimientos no funcionales

Son limitaciones del servicio que ofrece el sistema, restricciones, los no funcionales
aplican el sistema todo, como características o servicios individuales del sistema.
Afecta el sistema global de un sistema y esto gran atiza que se cumpla los requisitos del
sistema
 5

Requerimientos del producto:

Restringen el comportamiento del hardware y sus funcionalidades, implica que tan rapido se deve
de ejecutar el sistema y la memoria que requiere.

Requerimientos de la organización:

Se deriva de políticas y procedimientos del cliente y del desarrollador, esta tambien define como se
le dara el uso del sistema, el entorno y los procesos que utilizan.

Requerimientos externos:

Cubre los factores externos al sistema y su proceso en el desarrollo, regula lo que debe de hacer el
programa para ser aceptado, esto lleva a los requerimientos legislativos que se tiene que seguir
para que el sistema este deacuerdo a la ley
 6

II. 4.2 El documento de requerimientos de software.

Un documento de especificación de software es un documento formal que describe lo que

los desarrolladores deben incluir en un sistema. Este documento contiene información detallada

sobre los requisitos del usuario y los requisitos del sistema. En algunos casos, los requisitos del

usuario y los requisitos del sistema se incluyen en la misma descripción, pero en otros casos, los

requisitos del usuario se definen como entradas a la especificación del sistema.

La documentación de requisitos es importante cuando los sistemas de software son

construidos por contratistas externos. Sin embargo, los métodos de desarrollo ágiles requieren

que los requisitos cambien tan rápidamente que los documentos de especificación se pierdan

cuando se escriben, por lo que se utilizan enfoques como la programación crítica y se recopilan

los requisitos de los usuarios. los usuarios escriben información en las tarjetas. Sin embargo, es

una buena idea escribir un breve documento de respaldo que describa los requisitos comerciales

y los requisitos reales del sistema. Los documentos de requisitos incluyen a muchos usuarios,

desde la alta dirección de la organización que paga por el sistema hasta los ingenieros que

desarrollan el sistema.

Un documento de requisitos de software es una compensación entre comunicar los

requisitos al cliente, definir claramente los requisitos para los desarrolladores y especificadores e

incluir información sobre posibles desarrollos del sistema. La información sobre los cambios

esperados ayuda tanto a los diseñadores de sistemas a evitar decisiones de diseño vinculantes

como a los ingenieros de mantenimiento del sistema que necesitan adaptar el sistema a los

nuevos requisitos. El nivel de detalle contenido en un documento de especificación depende del

 7

tipo de sistema que se esté diseñando y del proceso de desarrollo que se utilice. La seguridad y la

protección deben analizarse exhaustivamente, por lo que los requisitos de los sistemas deben

detallarse. Cuando se utiliza un proceso de desarrollo interno, los documentos de requisitos son

menos detallados y las ambigüedades se pueden resolver durante el desarrollo del sistema.

III. 4.3 Especificación de requerimientos.

Una especificación de software es un documento que describe los requisitos del usuario y

del sistema. Los requisitos del usuario deben ser claros, concisos, fáciles de entender, completos,

coherentes y describir los requisitos funcionales y no funcionales. Por otro lado, los requisitos

del sistema son un conjunto extenso de requisitos de usuario que los ingenieros de software

utilizan como punto de partida para el diseño del sistema. El nivel de detalle contenido en un

documento de especificación depende del tipo de sistema que se esté diseñando y del proceso de

desarrollo que se utilice. Las especificaciones de software son documentos dinámicos que

resultan útiles para ayudar a los administradores y equipos de desarrollo a crear software que

cumpla con sus expectativas.

 8

Los requisitos del usuario están escritos en lenguaje natural y complementados con

diagramas y tablas apropiados en el documento de especificaciones. En este momento, las

especificaciones del sistema también se escriben en lenguaje natural, pero también se utilizan

otras notaciones en forma de figuras, modelos gráficos del sistema y modelos matemáticos del

sistema. Los ejemplos gráficos son muy útiles cuando quieres mostrar un cambio de estado o

cuando quieres describir una secuencia de acciones. A veces se utilizan expresiones matemáticas

formales para describir los requisitos de los sistemas de seguridad, pero rara vez se utilizan en

otros contextos.

Formas de escribir una especificación de requerimientos del sistema:

 9

4.3.1 Especificaciones estructuradas.

El lenguaje natural tiene reglas integradas para escribir los requisitos del sistema que

limitan el control del autor y garantizan que los requisitos sean consistentes. Sus necesidades se

recomiendan primero en las tarjetas, con un requisito para cada tarjeta, incluidos campos como

motivo de necesidad, dependencia de otros requisitos, fuente de necesidad, etc. Definir los

requisitos del sistema utilizando un enfoque estructural requiere definir patrones estándar y

expresarlos en un formato estructurado. Se puede establecer información sobre los objetos que

administra el sistema, las operaciones que realiza o los eventos que realiza. Además, se utilizan

modelos gráficos y fórmulas matemáticas formales para describir los requisitos del sistema,

especialmente los sistemas críticos.

Cuando use una forma estándar para especificar requerimientos funcionales, debe incluir

la siguiente información:

1. Una descripción de la función o entidad a especificar.

2. Una descripción de sus entradas y sus procedencias.

3. Una descripción de sus salidas y a dónde se dirigen.

4. Información sobre los datos requeridos para el cálculo u otras entidades en el sistema

que se utilizan (la parte “requiere”).

5. Una descripción de la acción que se va a tomar.

6. Si se usa un enfoque funcional, una precondición establece lo que debe ser verdadero

antes de llamar a la función, y una pos condición especifica lo que es verdadero

después de llamar a la función.

7. Una descripción de los efectos colaterales (si acaso hay alguno) de la operación.
 10

El uso de definiciones estructuradas elimina algunos de los problemas asociados con una

especificación de lenguaje natural, como la variabilidad y la dificultad de escribir requisitos

inequívocos. Sin embargo, los requisitos que describen cálculos complejos, como el cálculo de la

dosis de insulina, siguen siendo difíciles de redactar. Para resolver este problema, se puede

agregar información adicional a los requisitos en lenguaje natural, como tablas o modelos

gráficos del sistema, que pueden mostrar cómo avanzan los cálculos, cambiar el estado del

sistema, p.e. Las tablas son útiles cuando son posibles situaciones alternativas y es necesario

describir los pasos a seguir en cada situación.

Ejemplo:

IV. 4.4 Procesos de ingeniería de requerimientos

 11

En el segundo capítulo, se detallan cuatro actividades fundamentales en los procesos de

ingeniería de requerimientos: evaluación de la viabilidad, identificación y análisis de

requerimientos, especificación y validación.

Este enfoque iterativo se organiza alrededor de una espiral, y la salida es un documento

de requerimientos del sistema. La dedicación de tiempo y esfuerzo a cada actividad en cada

iteración varía según la etapa global del proceso y el tipo de sistema que se está desarrollando.

El modelo se divide en bucles internos y externos, donde se dedica más esfuerzo a

recopilar y comprender los requisitos detallados en los bucles externos.

El número de iteraciones de la espiral varía y la espiral se completa una vez que se

cumplen algunos o todos los requisitos del usuario.

Se puede utilizar el desarrollo ágil en lugar de la creación de prototipos, el código de

requisitos y la implementación del sistema.

La ingeniería de requisitos se considera un proceso de aplicación de métodos de análisis

estructurados, como el análisis orientado a objetos.

Esto implica analizar el sistema y desarrollar un conjunto de modelos gráficos, como

modelos de casos de uso, que luego sirven como especificación del sistema.

La recopilación de requisitos es una actividad centrada en el ser humano y los modelos

de sistemas rígidos pueden no ser suficientes para capturar los requisitos en evolución.
 12

La gestión de requisitos es un tema importante en este proceso, porque las personas, la

organización y el entorno organizacional del sistema pueden cambiar con el tiempo.

V. 4.5 Adquisición y análisis de requerimientos.

Después del estudio de viabilidad inicial, el siguiente paso en la ingeniería de requisitos

es la adquisición y el análisis. En este proceso, los ingenieros de software trabajan con los

clientes y usuarios finales del sistema para comprender el dominio de la aplicación, los servicios

que debe proporcionar el sistema, la funcionalidad que necesita el sistema, las limitaciones del

hardware, etc. Los requisitos y el análisis involucran a muchas personas diferentes, incluidos

usuarios finales, ingenieros, gerentes comerciales, expertos en el dominio y miembros sindicales.

Cada organización tiene una versión o versiones de este modelo general, en función de factores

locales como la experiencia de los empleados, el tipo de sistema a desarrollar, los estándares

utilizados, etc.

El proceso de adquisición y análisis de requerimientos es una etapa crucial en el

desarrollo de software. En esta etapa, los ingenieros de software trabajan con clientes y usuarios

finales del sistema para identificar y comprender sus necesidades y requerimientos. Los

participantes en el sistema pueden incluir usuarios finales, ingenieros de software,

administradores de negocios, expertos en dominio y representantes de asociaciones sindicales.

Las actividades principales del proceso son:

Descubrimiento de requerimientos: Este proceso implica interactuar con los participantes

del sistema para descubrir sus requerimientos, así como los requerimientos de dominio de los

participantes y la documentación existente.

 13

Clasificación y organización de requerimientos: Esta actividad consiste en agrupar

requerimientos relacionados y organizarlos en grupos coherentes, utilizando un modelo de la

arquitectura del sistema para identificar subsistemas y asociar los requerimientos con cada

subsistema.

Priorización y negociación de requerimientos: Cuando intervienen múltiples

participantes, los requerimientos pueden entrar en conflicto. Esta actividad se enfoca en priorizar

los requerimientos y encontrar y resolver conflictos de requerimientos mediante la negociación.

Especificación de requerimientos: Los requerimientos se documentan e ingresan en la

siguiente ronda de la espiral. Pueden producirse documentos de requerimientos iterativos con

retroalimentación continua de cada actividad a otras actividades.

El proceso de adquisición y análisis de requerimientos puede variar según factores

locales, como la experiencia del personal, el tipo de sistema a desarrollar y los estándares

utilizados. Es importante tener en cuenta que diferentes participantes pueden tener diferentes

visiones de la importancia y prioridad de los requerimientos, y algunas veces pueden entrar en

conflicto. Durante el proceso, se deben organizar negociaciones regulares con los participantes

para alcanzar compromisos.

 14

4.5.1 Descubrimiento de requerimientos.

El descubrimiento de requisitos es el proceso de recopilar información sobre los sistemas

existentes y deseados y extraer los requisitos del sistema y del usuario a partir de esta

información. En este paso, se utilizan fuentes de información como documentos, participantes

del sistema y requisitos similares del sistema. La interacción con los participantes proviene de

entrevistas y observaciones; se pueden utilizar escenarios y ejemplos para ayudar a los

participantes a comprender la naturaleza del sistema. Los participantes van desde

administradores y usuarios finales hasta participantes externos, como agencias reguladoras que

hacen cumplir la aprobación del sistema. Por ejemplo, los participantes que se incluyen para el

sistema de información de pacientes en atención a la salud mental son:

1. Pacientes cuya información se registra en el sistema.

2. Médicos que son responsables de valorar y tratar a los pacientes.

3. Enfermeros que coordinan, junto con los médicos, las consultas y suministran algunos

tratamientos.

4. Recepcionistas que administran las citas médicas de los pacientes.

5. Personal de TI que es responsable de instalar y mantener el sistema.

6. Un director de ética médica que debe garantizar que el sistema cumpla con los

lineamientos éticos actuales de la atención al paciente.

7. Encargados de atención a la salud que obtienen información administrativa del sistema.

8. Personal de archivo médico que es responsable de garantizar que la información del

sistema se conserve, y se implementen de manera adecuada los procedimientos de

mantenimiento del archivo.

 15

4.5.2 Entrevistas.

Las entrevistas formales o informales con participantes del sistema son una parte común

de la ingeniería de requerimientos. Estas entrevistas pueden ser de dos tipos: cerradas, con

preguntas preestablecidas, y abiertas, sin agenda predefinida. La ingeniería de requerimientos se

basa en las respuestas a las preguntas formuladas durante las entrevistas, y los requerimientos se

derivan de estas respuestas.

Sin embargo, las entrevistas pueden presentar desafíos en términos de comprensión de los

requerimientos desde el dominio de la aplicación. Por un lado, los especialistas en la aplicación

utilizan terminología específica y jerga que pueden dificultar la comprensión de los

requerimientos por parte de los ingenieros de requerimientos. Por otro lado, cierto conocimiento

del dominio es tan familiar para los participantes que puede ser difícil para ellos explicarlo, lo

que puede llevar a una incompleta o malinterpretada de los requerimientos.

Además, las entrevistas no son una técnica efectiva para comprender los requerimientos y

las restricciones de la organización, ya que existen relaciones sutiles de poder entre los diferentes

miembros en la organización. Estas relaciones pueden influir en la forma en que los participantes

responden a las preguntas y en la información que comparten.

En resumen, las entrevistas pueden ser una parte valiosa de la ingeniería de

requerimientos, pero también pueden presentar desafíos en términos de comprensión de los

requerimientos y la influencia de las relaciones de poder en la organización.

Las entrevistas formales o informales con los participantes del sistema son una parte

común del proceso de planificación. Hay dos tipos de entrevistas: entrevistas cerradas con

preguntas específicas y entrevistas abiertas sin un tema definido. Los requisitos se basan en las
 16

respuestas a las preguntas durante la entrevista y los requisitos se basan en estas respuestas. Sin

embargo, los entrevistadores pueden tener dificultades para comprender los requisitos del área de

solicitud. Actualmente, los expertos en aplicaciones utilizan términos y jerga específicos que

pueden dificultar que los ingenieros comprendan sus requisitos. Por otro lado, algunos

conocimientos del dominio son muy familiares para los participantes y difíciles de explicar, lo

que puede dar lugar a requisitos incompletos o malentendidos. Además, las entrevistas no son

un método eficaz para comprender las necesidades y limitaciones de la organización debido a las

relaciones débiles entre los miembros de la organización. Estas relaciones afectan la forma en

que los participantes responden a las preguntas y la información que comparten las entrevistas

pueden ser una parte importante de la ingeniería organizacional, pero también pueden ser un

desafío en términos de comprensión de los requisitos y el impacto de las relaciones de poder en

la organización.

4.5.3 Escenarios

Las características de los requisitos son de diferentes tipos y niveles de detalle y pueden

incluir diferentes tipos de información. La función comienza con un bosquejo de la interacción,

se desarrolla a lo largo del proceso de venta y agrega detalles para describir completamente esa

interacción.
 17

La información del usuario utilizada en programas reales es un tipo de especificación.

Esta información describe el contexto real en el que los usuarios interactúan con su sistema y le

ayuda a comprender sus necesidades y deseos.

Las características de los requisitos son una herramienta útil para que los ingenieros de

requisitos comprendan y describan las interacciones del usuario con los sistemas informáticos,

permitiéndoles capturar y analizar los requisitos del sistema. Por lo general pueden incluir:

1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario.

2. Una descripción en el escenario del flujo normal de los eventos.

3. Una descripción de qué puede salir mal y cómo se manejaría.

4. Información de otras actividades que estén en marcha al mismo tiempo.

5. Una descripción del estado del sistema cuando termina el escenario.

La adquisición basada en condiciones implica trabajar con los participantes para definir

las condiciones y capturar los detalles que se incluirán en esas condiciones. Estos últimos pueden

escribirse en texto y añadirse a diagramas, fotografías, etc. Por ejemplo, puede utilizar un

enfoque más estructurado.

Sistema MHC-PMS.
 18

4.5.5 Etnografía.

Los sistemas de software no existen de forma aislada, sino que se encuentran en un

contexto social y organizacional que puede influir en sus requisitos. La etnografía es una técnica

de investigación utilizada para comprender los procesos organizacionales y generar requisitos de

apoyo para esos procesos. Este método permite a los analistas comprender cómo el contexto

social y organizacional influye en el funcionamiento continuo del sistema, lo cual es fundamental

para su éxito.

Dado que el trabajo es un segundo trabajo, puede resultar difícil expresar claramente los

detalles de su trabajo. La etnografía ayuda a identificar los requisitos del sistema que reflejan la

forma en que trabajan las personas, en lugar de los procedimientos formales definidos por la

organización.

En resumen, la teoría social es una herramienta útil para comprender el impacto del

contexto social y organizacional en la gestión de sistemas informáticos, lo que permite a los

ingenieros de requisitos capturar y analizar los requisitos del sistema.

La etnografía es una técnica de investigación utilizada para comprender los procesos

organizacionales y generar requisitos de apoyo para esos procesos. Este método, junto con un

modelo de muestra, puede identificar problemas y preguntas que pueden discutirse con un

experto humano. La etnografía es útil para descubrir requisitos del sistema que reflejan la forma

en que las personas trabajan actualmente, en lugar de procedimientos formales definidos por la

organización.

Sin embargo, la antropología no es el único método para obtener requisitos; debe usarse

para complementar otros métodos, como el análisis de casos de uso. La investigación social
 19

puede proporcionar detalles importantes del proceso que faltan en otros métodos de obtención de

requisitos, pero no es adecuada para identificar requisitos organizacionales o regionales.

La teoría social es una herramienta útil para comprender el impacto del contexto social y

organizacional en la gestión de sistemas informáticos, lo que permite a los ingenieros de

requisitos capturar y analizar los requisitos del sistema. La etnografía, junto con el muestreo,

puede identificar problemas y preguntas que pueden discutirse con un antropólogo, pero no es

una manera perfecta de encontrar una solución.

VI. 4.6 Validación de requerimientos

1.-Comprobaciones de validez: Identificación de funciones necesarias mediante un

análisis más profundo, considerando las diversas necesidades de los usuarios en el sistema.
 20

2.-Comprobaciones de consistencia: Evita conflictos en los requerimientos, asegurando

que no haya restricciones o malas funciones del sistema.

3.-Comprobaciones de totalidad: Garantizar que el documento de requerimientos incluya

todas las restricciones que el usuario pueda permitir

4.-Comprobaciones de realismo: Verificar la posibilidad de implementar los

requerimientos con base en el conocimiento tecnológico actual,

5.-Verificabilidad: Escribir los requerimientos de manera que sean verificables mediante

pruebas, reduciendo problemas entre cliente el cliente y el contratista

21
 22

VII. 4.7 Administración de requerimientos.

Los requisitos de los sistemas informáticos a gran escala cambian constantemente. En

parte, esto se debe a que fue desarrollado para resolver problemas complejos y poco

comprendidos. La comprensión de los participantes sobre estos problemas cambia

constantemente y los requisitos del sistema están evolucionando para reflejar estas diferentes

perspectivas sobre los problemas. Estos desarrollos también se ven afectados por los cambios en

nuestro negocio y entorno a lo largo del tiempo. La etnografía es un método útil para comprender

estos cambios porque nos permite ver los requisitos del sistema que reflejan la forma en que

trabajan las personas, en lugar de los métodos formales definidos por la organización. Sin

embargo, la antropología no es la única forma de obtener requisitos, sino que debe utilizarse para

complementar otros métodos, como el análisis de casos de uso.

Una vez que el sistema esté instalado y utilizado con regularidad, inevitablemente

aparecerán nuevos requisitos. Es difícil para los usuarios y clientes del sistema predecir qué

efectos tendrá el nuevo sistema en sus procesos comerciales y en su trabajo. A medida que los

usuarios finales experimentan el sistema, descubren nuevas necesidades y prioridades. Hay

muchas razones por las que el cambio es inevitable:

1.El entorno empresarial y técnico de un sistema siempre cambia después de la

instalación. Es posible que se introduzca nuevo hardware y que sea necesario interconectar el

sistema

con otros sistemas, cambiar las prioridades comerciales (y por lo tanto cambios en el

sistema de soporte necesario) e introducir nuevas leyes y regulaciones que el sistema debe

cumplir.
 23

2. Quienes pagan por el sistema y los usuarios del sistema no suelen ser los mismos. Los

clientes del sistema establecen requisitos debido a limitaciones organizativas y presupuestarias.

Esto puede entrar en conflicto con los requisitos del usuario final y, en el momento de la entrega,

es probable que sea necesario agregar nuevas funciones para respaldar al usuario

para que el sistema pueda alcanzar sus objetivos.

3. Los sistemas grandes a menudo tienen una base de usuarios diversa

donde muchas personas tienen diferentes requisitos y prioridades que pueden chocar o

colisionar. Inevitablemente habrá compromisos en los requisitos finales del sistema y, con la

experiencia, a menudo se descubre que es necesario cambiar el equilibrio de soporte para

diferentes usuarios.

La gestión de requisitos es el proceso de comprender y controlar los cambios en los

requisitos del sistema. Para evaluar el impacto de los requisitos cambiantes, es necesario realizar

un seguimiento de los requisitos individuales y mantener relaciones entre los requisitos

dependientes. También es necesario establecer un proceso formal para realizar cambios en las

propuestas y vincularlas con los requisitos del sistema. El proceso formal de gestión de

reclamaciones debe comenzar tan pronto como esté disponible un borrador del documento de

reclamaciones. Sin embargo, la gestión de cambios de requisitos debe iniciarse durante el

proceso de adquisición de requisitos.

4.7.1 Planeación de la administración de requerimientos.

La planificación es el primer paso en el proceso de gestión de requisitos. Este paso

determina el nivel de información necesaria para la gestión de requisitos. En el apartado de

gestión de requisitos deberás decidir:

 24

La gestión de requisitos es el proceso de identificación, seguimiento y gestión de los

requisitos del sistema. Este proceso es importante para garantizar la confiabilidad, coherencia,

precisión y validez de los requisitos durante todo el proyecto. Algunos aspectos clave de la

gestión de requisitos son:

1. Identificación de requisitos: cada requisito debe identificarse de forma única para que

pueda compararse con otros requisitos y utilizarse para una revisión posterior.

2. El proceso de gestión de cambios: este proceso es un conjunto de actividades que

permiten gestionar cambios en los requisitos, evaluar la efectividad y los costos del cambio.

3. Política de seguimiento: Esta política describe la relación entre cada requisito y la

relación entre los requisitos a escribir y el diseño del sistema. También deberá definir cómo se

mantendrán estos registros.

4. Herramientas de soporte: La gestión de requisitos requiere soporte automatizado y

herramientas de software para gestionar los requisitos de seguimiento y control. Estas

herramientas van desde sistemas de gestión de aplicaciones especializados hasta sistemas

simples de hojas de cálculo y bases de datos.

La gestión de requisitos es importante para gestionar los cambios en los requisitos y

garantizar que el sistema satisfaga las necesidades del usuario y del negocio. Es importante

contar con un proceso formal para gestionar los cambios en los requisitos y mantener la

confiabilidad y coherencia de los requisitos durante todo el proyecto.

Aspectos clave de la gestión de requisitos en el contexto de la ingeniería de requisitos y el

desarrollo de sistemas de software. Éstos son algunos de los puntos principales:

 25

1. Identificación de requisitos: Cada requisito debe identificarse por separado y

compararse con otros requisitos para facilitar el seguimiento y la evaluación.

2. Gestión de cambios: este proceso implica evaluar el impacto de los cambios en los

requisitos mediante el seguimiento de los requisitos individuales y el mantenimiento de

relaciones entre los requisitos dependientes.

3. Política de seguimiento: Esta política describe la relación entre cada requisito y la

relación entre los requisitos a escribir y el diseño del sistema. También deberá definir cómo se

mantendrán estos registros.

4. Herramientas de soporte: La gestión de requisitos debe ser respaldada automáticamente

con herramientas de software, desde sistemas de gestión de requisitos especializados hasta hojas

de cálculo y sistemas de bases de datos simples. Etnografía y creación de prototipos para

complementar otros enfoques en los requisitos adquiridos. También muestra que los requisitos de

los grandes sistemas de TI cambian constantemente y es necesario planificar cómo gestionar los

cambios en los requisitos durante el proceso de adquisición.

4.7.2 Administración del cambio en los requerimientos.

La administración del cambio en los requerimientos es un proceso esencial que debe

aplicarse a todas las propuestas de cambio una vez aprobado el documento de requerimientos.

Este proceso es fundamental para determinar si los beneficios de implementar nuevos

requerimientos justifican los costos de la implementación. La ventaja de utilizar un proceso

formal para la administración del cambio es que todas las propuestas de cambio se tratan de
 26

manera consistente y los cambios al documento de requerimientos se realizan de forma

controlada.

El proceso de administración del cambio consta de tres etapas principales: la

identificación de los cambios propuestos, la evaluación de los cambios y la implementación de

los cambios aprobados. Durante la etapa de evaluación, se analizan los cambios propuestos para

determinar su viabilidad, impacto y justificación. Una vez aprobados, los cambios se

implementan de manera controlada en el documento de requerimientos.

La gestión de requerimientos es fundamental para el éxito de un proyecto de software, ya

que establece lo que el sistema debe hacer en relación a procesos, consultas, informes, pantallas,

avisos, control de usuarios y otros elementos que el negocio necesita. La gestión de

requerimientos engloba todas las actividades y verificaciones necesarias para descubrir, analizar,

documentar y mantener el conjunto de requerimientos de un proyecto en la implementación de

un sistema de software.

1. Análisis de problemas y especificación de cambios: comience identificando el

problema en los requisitos o la solicitud de cambio específica. En este punto, puedes analizar la

efectividad del problema o idea, realizar cambios específicos o eliminar la aplicación.

2. Análisis de cambios y estimación de costos: La efectividad del cambio propuesto se

evalúa utilizando información de monitoreo y conocimiento general de los requisitos del sistema.

Los costos de modificación se determinan en función de la revisión de documentos, el diseño del

sistema y los requisitos de implementación. Posteriormente se decidirá si se procede con el

cambio de requisitos.

3. Implementación de cambios: Se modificarán las especificaciones y, en su caso, el

diseño e implementación del sistema. Prepare el borrador del documento de modo que se puedan
 27

realizar cambios sin sobrescribirlo ni reorganizarlo, minimice las referencias externas y haga que

las partes del documento sean lo más consistentes posible.

El control de cambios de requisitos es un proceso fundamental en la gestión de proyectos

y el desarrollo de software que se centra en gestionar y controlar los cambios propuestos a los

requisitos del sistema. Este proceso es fundamental para identificar, documentar y validar todos

los cambios en los requisitos del proyecto antes de su implementación, mantener el control del

proyecto y garantizar que los requisitos se gestionen adecuadamente.