Ingeniería de requisitos

En este componente formativo se abordan los saberes de ingeniería de

requisitos: ciclo de vida del software fases y objetivos, modelos,
características, caracterización de la fase de definición de requisitos y
herramientas para el uso de captura de requisitos que se usan para el
desarrollo del software.

A través del ciclo de vida del software, desde la planificación hasta el

mantenimiento, se asegura que el software sea desarrollado conforme a
los requerimientos establecidos, garantizando la calidad y satisfacción
del cliente

Introducción
En este módulo se estudiarán los conceptos básicos sobre la ingeniería
de requisitos, sus fases técnicas y las herramientas necesarias para la
gestión y especificación de los requisitos.

1. Ciclo de vida del software

También conocido como (SDLC o Systems Development Life Cycle), es el
proceso que se sigue para construir y hacer evolucionar un determinado
software. El ciclo de vida permite iniciar una serie de fases mediante las
cuales se procede a la validación y al desarrollo del software
garantizando que se cumplan los requisitos para la aplicación y
verificación de los procedimientos de desarrollo; para ello, se utilizan
métodos del ciclo del software, que indican distintos pasos a seguir para
el desarrollo de un producto.
Si bien existen diferentes ciclos de desarrollo de software, la
normativa ISO/IEC/IEEE 12207:2017 establece:
Un marco común para los procesos del ciclo de vida de los programas
informáticos, con una terminología bien definida, a la que pueda
remitirse la industria del software. Contiene procesos, actividades y
tareas aplicables durante la adquisición, el suministro, el
desarrollo, el funcionamiento, el mantenimiento o la eliminación
de sistemas, productos y servicios informáticos. Estos procesos
del ciclo de vida se llevan a cabo mediante la participación de los
interesados, con el objetivo final de lograr la satisfacción del cliente
(s.p.).
A continuación, se indican cuáles son los elementos que integran un
ciclo de vida:
 1.1. Fases:
Una fase es un conjunto de actividades relacionadas con un objetivo en
el desarrollo del proyecto. Se construye agrupando tareas (actividades
elementales) que pueden compartir un tramo determinado del tiempo
de vida de un proyecto. La agrupación temporal de tareas impone
requisitos temporales correspondientes a la asignación de recursos
(humanos, financieros o materiales).
Las fases del modelo de ciclo del software son: planificación, análisis,
diseño, implementación, pruebas y mantenimiento, las cuales se
describen en la siguiente figura.
FASE PLANIFICACIÓN:
En esta primera fase se realiza el planteamiento del problema, se
definen alcances y objetivos del software.
Objetivos: estudio de viabilidad, realizar planificación detallada.
FASE ANÁLISIS (definición de requisitos):
Esta fase busca definir los requisitos que son los que dirigirán el
desarrollo del proyecto de software.
Objetivos: conocer los requisitos, asegurar que los requisitos son
alcanzables, formalizar acuerdo con el cliente.
FASE DISEÑO:
En esta fase se estudian posibles opciones de implementación para el
software que hay que construir, estructura general del mismo.
Objetivos: Identificar soluciones tecnológicas, asignar recursos
materiales, proponer identificar y seleccionar, establecer métodos de
validación, ajustar especificaciones.
FASE PRUEBAS:
Esta fase busca detectar fallos cometidos en las etapas anteriores para
corregirlos.

Objetivos: Realizar los ajustes necesarios para corregir posibles errores

o inconsistencias.
FASE MANTENIMIENTO:
En esta fase se realizan tres puntos referenciados: mantenimiento
correctivo, mantenimiento adaptativo y mantenimiento perfectivo.
Objetivos: Operación asegurar que el uso del proyecto es el que se
pretendía, mantenimiento.

1.2. Entregables:
Son los productos intermedios que generan las fases. Pueden ser
materiales o inmateriales (documentos, software). Los entregables
permiten evaluar la marcha del proyecto mediante comprobaciones de
su adecuación o no a los requisitos funcionales y de condiciones de
realización previamente establecido.
1.2. Paradigmas de los modelos de ciclo de vida del software
Con la finalidad de proporcionar una metodología común entre el cliente
y la empresa de software, se utilizan los modelos de ciclos de vida o
paradigmas de desarrollo de software para plasmar las etapas y la
documentación necesaria, de manera que cada fase se valide antes de
continuar con la siguiente.
Un modelo de ciclo de vida de software es una vista de las actividades
que ocurren durante el desarrollo de software e intenta determinar el
orden de las etapas involucradas y los criterios de transición asociados
entre estas.
Según la norma 1074 IEEE se define al ciclo de vida del software como:
Una aproximación lógica a la adquisición, el suministro, el
desarrollo, la explotación y el mantenimiento del software.
La ISO/IEC 12207 Information Technology / Software Life Cycle Processes
señala que es:
Un marco de referencia que contiene los procesos, las actividades y las
tareas involucradas en el desarrollo, la explotación y el mantenimiento
de un producto de software, abarcando la vida del sistema desde la
definición de los requisitos hasta la finalización de su uso (2008).
Existen modelos preestablecidos con los cuales se pude elaborar un
proyecto; a continuación, se mencionan los diferentes paradigmas de
modelos de ciclo de vida para desarrollar software.
Paradigma tradicional
Los paradigmas tradicionales se identifican, fundamentalmente, por ser
lineales, es decir se trata de completar cada proceso de principio a fin
hasta que quede listo para avanzar a la segunda fase del ciclo del
software.
Si bien es verdad que las metodologías actuales están basadas en lo que
fueron los paradigmas tradicionales, hoy en día se ha evolucionado, sin
embargo, los paradigmas tradicionales se mantienen.
Desventaja:
Pérdida de tiempo si se encuentran errores en una fase avanzada porque
al devolverse se debe pasar nuevamente por todas las fases y
reestructurar de acuerdo con las modificaciones.
Paradigma orientado a objetos:
Las etapas de desarrollo de software en el paradigma orientado a
objetos, se conforma principalmente por la creación de clases, análisis
de requisitos y el diseño. Con este paradigma se pretende que el código
fuente sea reutilizable para otros proyectos.
Paradigma de desarrollo ágil
El objetivo de este paradigma es el desarrollo de proyectos en poco
tiempo, se simplifican procesos tediosos, se agilizan las fases del
desarrollo y las interacciones se hacen en corto tiempo.
Una de las principales diferencias con los paradigmas anteriores es que
el cliente se ve involucrado en el proyecto durante el desarrollo de este,
así, el cliente sugiere mejoras, propone ideas y se mantiene al tanto del
desarrollo del producto, a diferencia del paradigma tradicional y el
orientado objeto donde el cliente únicamente está al principio.
A continuación, se revisan los modelos del paradigma tradicional más
utilizados.
Modelo en cascada
Uno de los primeros modelos de ciclo de vida del desarrollo fue
establecido por W. Royce en 1970 y es conocido como el “modelo de
cascada” (waterfall model).
En su concepción básica, cada una de las actividades genera, como
salidas, productos y modelos que son utilizados como entradas para el
proceso subsiguiente; esto supone que una actividad debe terminarse
(por lo menos, en algún grado) para empezar la siguiente.

Modelo espiral
Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos
repetitivos para ir ganando madurez en el producto final. El espiral se
repite las veces que sea necesario hasta que el cliente o el usuario
obtenga la satisfacción de sus necesidades.
En este modelo hay 4 actividades que envuelven a las etapas:
planificación, análisis de riesgo, implementación y evaluación. Una de
sus principales ventajas es que los riesgos van disminuyendo conforme
avanzan los ciclos o interacciones.
Modelo iterativo o por prototipos
Este modelo consiste en un procedimiento que permite al equipo de
desarrollo diseñar y analizar una aplicación que represente el sistema
que será implementado (McCracken y Jackson, 1982).
Objetivos
[Link] un medio eficaz para aclarar los requisitos de los usuarios e
identificar las características de un sistema que deben cambiarse o
añadirse.
[Link] el prototipo se puede verificar la viabilidad del diseño de
un sistema.
Las etapas del modelo son:
1. Colecta y refinamiento de los requerimientos y proyecto rápido.
 Análisis.
 Especificación del prototipo.
2. Diseño rápido.
3. Construcción del prototipo.
 4. Evaluación del prototipo por el cliente.
5. Refinamiento del prototipo.
 Diseño técnico.
 Programación y test.
 Operación y mantenimiento.
6. Producto de ingeniería.

Con

respecto a los modelos del ciclo de vida del paradigma ágil, estos
se caracterizan por estar basados en etapas del ciclo de vida del
software tradicional, pero combinándolas con algunas técnicas, al
respecto se pueden revisar los siguientes

Modelo Scrum
Este modelo se basa en el desarrollo incremental, es decir conforme
pasen las fases y la iteración mayor será el tamaño del proyecto que se
está desarrollando.
1. Product Backlog.
2. Sprint Backlog.
3. Sprint Planning Meeting.
1. Daily Scrum.
2. Sprint Review.
3. Sprint Retrospective

El Scrum consiste en realizar un análisis de los requerimientos del

sistema (Product Backlog), señalar cuáles serán los objetivos a corto o
mediano plazo dentro de un sprint, o sea, la fase de desarrollo.
Posteriormente, los desarrolladores harán lo suyo, se realizarán algunas
pruebas y se retroalimentará de acuerdo con lo conseguido al terminar
la última fase.
Ventajas
  Gestión regular de las expectativas del usuario: los usuarios
participan y proponen soluciones.
 Resultados anticipados: no es necesario esperar hasta el final
para ver resultados.
 Flexibilidad y adaptación: se adapta a cualquier contexto, área
o sector.
 Gestión sistemática de riesgos: los problemas son gestionados
en el mismo momento de su aparición.

Modelo Kanban
David J. Anderson (reconocido como el líder de pensamiento de la
adopción del Lean/Kanban para el trabajo de conocimiento), formuló el
método Kanban como una aproximación al proceso evolutivo e
incremental y al cambio de sistemas para las organizaciones de trabajo.
El método está enfocado en llevar a cabo las tareas pendientes y los
principios más importantes pueden ser divididos en cuatro principios
básicos y seis prácticas.
El modelo Kanban es uno de los modelos más visuales de las
metodologías ágiles; este consiste en la creación de un tablero con
etiquetas, donde se seccionan cada una de las fases de su desarrollo,
además se clasifican de acuerdo con los equipos de trabajo y se les
asignan objetivos a corto, mediano y largo plazo.
Modelo XP o programación extrema
La programación extrema o eXtreme Programming (XP) es un enfoque
de la ingeniería de software formulado por Kent Beck, autor del primer
libro sobre este tema: Extreme Programming Explained: Embrace
Change (1999). Esta metodología es adaptable según las necesidades y
requerimientos a implementar, además, el cliente se encuentra
involucrado en el proceso de desarrollo lo que hace que el producto
pueda ser terminado en un menor tiempo.
Características principales de la programación extrema:
 1. Tipo de desarrollo iterativo e incremental.
2. Pruebas unitarias.
3. Trabajo en Equipo.
4. Trabajo junto al cliente.
1. Corrección de errores.
2. Reestructuración del código.
3. El código es de todos.
4. El código simple es la clave.

2. Fase de definición de requisitos

En esta primera fase del ciclo de vida del software, también llamada
fase de análisis se recopila, se examina y se formulan los requisitos del
cliente, así como la verificación de las posibles restricciones que se
puedan aplicar.
Por eso, la etapa de análisis en el ciclo de vida del software corresponde
al proceso a través del cual se intenta descubrir qué es lo que realmente
se necesita y se llega a una comprensión adecuada de los
requerimientos del sistema (las características que el sistema debe
poseer).
La etapa de análisis es esencial debido a que sin esta no se sabe con
precisión qué es lo que se necesita y ningún proceso de desarrollo
permitirá obtenerlo. El problema que se presenta es que al inicio del
desarrollo el cliente no sepa exactamente lo que necesita; por tanto, se
debe averiguar con ayuda de distintas técnicas.
De otra parte, la inestabilidad de los requerimientos de un sistema es
inevitable, pues se estima que 25% de los requerimientos iniciales de un
sistema cambian antes de que el sistema comience a utilizarse. Por ello,
muchas prácticas resultan efectivas para gestionar adecuadamente los
requerimientos de un sistema y, en cierto modo, controlar su evolución.
Fase: Análisis (definición de requisitos).

Actividad: Definición del alcance del proyecto.

 Identificación del negocio.
o Artefacto: Modelo del negocio.
 Toma de requerimientos.
o Análisis y realización de casos de uso.
 Estudio de procesos de negocio.
o Modelo de procesos y actividades de negocio.
 Calendarización del proyecto.
o Cronograma del proyecto.

3. Requisitos
Un requisito es una condición o capacidad que necesita el usuario para
resolver un problema o conseguir un objetivo determinado (IEEE, 1990).
Los requisitos comunican las expectativas de los consumidores de
productos software; de otra parte, los requisitos pueden ser obvios o
estar ocultos, conocidos o desconocidos, esperados o inesperados,
desde el punto de vista del cliente.

3.1 Importancia de los requisitos

Los requisitos cobran importancia dentro del ciclo de vida del software,
puesto que:
Establecen el alcance del trabajo subsecuente, pueden definir
estrategias de desarrollo, riesgos, tomar decisiones de negocio
(viabilidad de negocio), de proyecto (tiempo, recursos), de sistema
(arquitectura).
Indican al equipo del proyecto qué requieren los usuarios (necesidades
de negocio).
El éxito o fracaso de un proyecto está altamente influenciado por la
calidad de los requisitos y el proceso para gestionarlos durante el
desarrollo de un producto.
En la siguiente figura se pueden revisar las características que los
requisitos deben cumplir de acuerdo con Pfleeger (2002).
Necesario
Si se tiene alguna duda acerca de la necesidad del requerimiento, se
puede preguntar “¿Qué sería lo peor de no incluirlo?”. Si no se
encuentra una respuesta o cualquier consecuencia, entonces es
probable que no sea un requerimiento necesario.
Consistente
Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
Factible
El requerimiento deberá de ser totalmente factible y dentro de
presupuesto, calendario y otras restricciones, si se tiene alguna duda de
su factibilidad, hay que investigar, generar pruebas de concepto para
saber su complejidad y factibilidad, si aun así el requerimiento es no
factible, hay que revisar la visión del sistema y replantear el
requerimiento.
Priorizado
Categorizar el requerimiento nos ayuda a saber el grado de necesidad
del mismo: esencial/crítico, deseado, opcional verificable.
Rastreable
La especificación se debe organizar de tal forma que cada función del
sistema se pueda rastrear hasta su conjunto de requerimientos
correspondiente. Facilita las pruebas y la validación del diseño.
Completo
Un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, si se proporciona la información suficiente para su
comprensión.
Correcto
Acuerdo entre dos partes. Contiene una sola idea
Modificable
Los cambios en los requisitos deben hacerse de manera sistemática, y
debe tenerse en cuenta su impacto en otros requisitos.
Verificable
Si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe si
se cumplió con él o no? Debe ser posible verificarlo ya sea por
inspección, análisis de prueba o demostración. Cuando se escriba un
requerimiento, se deberán determinar los criterios de aceptación.
Claro
Un requerimiento es conciso si es fácil de leer y entender, su redacción
debe ser simple y clara para quienes lo consulten en un futuro.
3.2 Clasificación
Los requerimientos se pueden definir de distintas maneras, la primera
clasificación se encuentra relacionada con el nivel de descripción con la
que cuentan estos y dentro de este tipo de clasificación se encuentran:

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: En la siguiente clasificación se observa

la que se da a los requerimientos del sistema, la cual se encuentra
dividida con base en lo que se va a describir, las clasificaciones son:

Requerimientos funcionales:Son declaraciones de los servicios que

debe proporcionar el sistema, de la manera en que este debe reaccionar
a entradas particulares; o también pueden declarar explícitamente lo
que el sistema no debe hacer.

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 se encuentra todo lo referente a la fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento.
En la siguiente tabla se presentan algunos ejemplos sobre requisitos
funcionales y no funcionales.

Funcionales
Se debe ingresar cédula, nombre y teléfono de cada cliente.
Se requiere un listado de clientes por zona.
No funcionales
Las consultas deben resolverse en menos de 3 segundos.
El lenguaje de programación debe ser Java.

4. Ingeniería de requisitos
Las siguientes son definiciones de ingeniería de requisitos de algunos
autores.

La ingeniería de requisitos es la disciplina para desarrollar una

especificación completa, consistente y no ambigua, la cual
servirá como base para acuerdos comunes entre todas las
partes involucradas y en dónde se describen las funciones que
realizará el sistema. - (Boehm, 1979)

La ingeniería de requisitos es el proceso de estudiar las

necesidades del usuario para llegar a una definición de
requisitos de sistema, hardware o software. - (IEEE, 1990).

La ingeniería de requisitos puede considerarse como un proceso

de descubrimiento y comunicación de las necesidades de
clientes y usuarios y la gestión de los cambios de dichas
necesidades. - (Amador, 2000)

El término IR “ingeniería de requisitos” ha surgido para englobar los

procesos de desarrollo y gestión de requisitos en el ciclo de vida del
software, el primer término (ingeniería) se enfoca en las actividades de
obtención, análisis, especificación y validación de los requisitos que
permitirá alcanzar los objetivos del negocio y el segundo (requisitos)
está centrado en la administración de los mismos y tiene como propósito
central la gestión de los cambios y la trazabilidad, de esta forma la IR
proporciona el mecanismo apropiado para:

 Entender lo que el cliente quiere.

 Analizar las necesidades.

 Evaluar la factibilidad.

 Negociar una solución razonable.

 Especificar la solución sin ambigüedades.

 Validar la especificación.

 Administrar los requisitos conforme éstos se transforman en un

sistema operacional.

Etapas de la ingeniería de requisitos

 Hay cuatro (4) etapas en un proceso usual de ingeniería de

requisitos y que son utilizadas para el desarrollo de un producto
 único, a saber: elicitación, análisis, especificación y validación de
los requisitos.

Elicitación

Actividad involucrada en el descubrimiento de los requisitos del sistema.

Aquí los analistas deben trabajar junto con el cliente para descubrir el
problema que el sistema debe resolver, los diferentes servicios que el
sistema debe prestar y las restricciones que se pueden presentar.

Los principales objetivos que se deben alcanzar son los siguientes:

 Conocer el dominio del problema, de forma tal que los analistas

puedan entenderse con los clientes y usuarios y sean capaces de
transmitir dicho conocimiento al resto del equipo.
 Descubrir necesidades reales entre clientes y usuarios, haciendo
énfasis en aquellas que la mayor parte de las veces se asumen y
toman por implícitas.
 Consensuar los requisitos entre los propios clientes y usuarios
hasta obtener una visión común de los mismos.

Análisis

Sobre la base de la obtención realizada previamente, comienza esta fase

la cual tiene como propósito descubrir problemas con los requisitos del
sistema identificados hasta el momento, para ello se basa en los
siguientes objetivos:

 Detectar conflicto en los requisitos que suelen provenir de

distintas fuentes y presentar contradicciones o ambigüedades
debido a su naturaleza informal.
 Profundizar en el conocimiento del dominio del problema puede
facilitar el proceso de construir un producto útil para clientes y
usuarios (Durán, 2000).

En esta fase, el analista proporciona un sistema de retroalimentación

que refina el entendimiento conseguido en la etapa de obtención.

Especificación

Aquí se documentan los requisitos acordados con el cliente, en un nivel

apropiado de detalle. En la práctica, esta etapa se realiza conjuntamente
con el análisis, por lo que se puede decir que la especificación es el
“pasar en limpio” el análisis realizado previamente aplicando técnicas
y/o estándares de documentación, como la notación UML (Lenguaje de
Modelado Unificado), que es un estándar para el modelado orientado a
objetos, por lo que los casos de uso y la obtención de requisitos basada
en los casos de uso se utilizan cada vez más para la obtención de
requisitos.

Validación

Por último, la validación garantiza que los requisitos, una vez analizados
y resueltos los posibles conflictos, correspondan realmente a las
necesidades de clientes y usuarios, para evitar que, a pesar de que el
producto final sea técnicamente correcto, no sea satisfactorio. La
validación puede llevar al analista a reescribir algunas especificaciones
de requisitos y, en otros casos, a obtener nuevos, producto de la
aparición de necesidades que hasta entonces estaban ocultas, para
volver a evaluar el análisis inicial, o para corregir y perfeccionar el
conjunto de requisitos documentados.

Ingeniería de requisitos
El Ciclo de Vida del Software (SDLC) es el proceso estructurado para
desarrollar y mantener software, asegurando que cumpla con los
requisitos a través de diversas fases. Según la normativa ISO/IEC/IEEE
12207:2017, incluye procesos aplicables durante la adquisición,
desarrollo, operación, y mantenimiento del software, con el objetivo final
de satisfacer al cliente.

Fases del Ciclo de Vida:

1. Planificación: Definir el problema, alcance y objetivos del

proyecto.

2. Análisis: Determinar y documentar los requisitos del software.

3. Diseño: Especificar la estructura y soluciones tecnológicas.

4. Implementación: Crear y ensamblar el código.

5. Pruebas: Detectar y corregir errores.

6. Mantenimiento: Realizar ajustes correctivos, adaptativos y

perfectivos.
Entregables

Son productos intermedios (documentos o software) que permiten

evaluar el avance.

Paradigmas de Modelos de Ciclo de Vida:

1. Tradicional: Metodologías lineales (como el modelo en cascada),

con fases secuenciales.

2. Orientado a Objetos: Basado en la reutilización de clases y

módulos.

3. Ágil: Como Scrum, Kanban y XP, se enfoca en la adaptación

rápida a cambios y en la participación continua del cliente.

Modelos principales en cada paradigma:

 Cascada: Lineal, cada fase depende de la anterior.

 Espiral: Iterativo, reduce riesgos mediante ciclos repetitivos.

 Prototipos: Facilita la clarificación de requisitos y diseño

mediante prototipos.

 Scrum: Desarrollo incremental y regular retroalimentación.

 Kanban: Visual, con tableros para gestionar tareas.

 XP: Programación extrema, con trabajo colaborativo y constante

revisión del código.

Cada modelo tiene características específicas para adaptarse a

diferentes tipos de proyectos y necesidades.

La fase de definición de requisitos es el primer paso en el ciclo de vida

del software, en el que se recopilan, analizan y especifican los
requerimientos del cliente. Su objetivo es identificar con precisión las
necesidades y las limitaciones del sistema. Dado que los requisitos
pueden ser inestables (pudiendo variar hasta un 25% antes de la
implementación), se aplican técnicas de gestión para controlarlos
eficazmente y permitir que el proyecto se ajuste a estos cambios

Actividades de la Fase de Análisis:

Definición del alcance del proyecto: Incluye la identificación del negocio

(modelo de negocio), recopilación de requerimientos (casos de uso),
estudio de procesos de negocio (modelo de procesos) y la
calendarización (cronograma).

Importancia de los Requisitos:

Los requisitos establecen el alcance del proyecto, guían la toma de

decisiones (tiempo, recursos) y afectan directamente el éxito del
proyecto. Su calidad y gestión son cruciales para evitar errores en el
desarrollo.

Características de los Requisitos:

Un buen requisito debe ser:

Necesario, consistente, factible, priorizado, rastreable, completo,

correcto, modificable, verificable, y claro.

Clasificación de Requisitos:

Requisitos de usuario: Describen los servicios esperados del sistema y

las restricciones bajo las cuales debe operar, generalmente en lenguaje
natural y diagramas.

Requisitos de sistema:

Funcionales: Indican los servicios que el sistema debe proporcionar y

cómo debe responder.

No funcionales: Restricciones en los servicios, como tiempo de

respuesta, fiabilidad y estándares tecnológicos.

Ejemplos:

Funcionales: Ingreso de datos del cliente (cédula, nombre, teléfono).

No funcionales: Respuestas en menos de 3 segundos, uso del lenguaje

Java.

La ingeniería de requisitos crea una especificación precisa para acordar

las funciones del sistema, gestionando y adaptando los requisitos de
clientes y usuarios a lo largo del ciclo de vida del software.

Su objetivo es entender lo que el cliente necesita, evaluar su viabilidad,

negociar una solución razonable, y validar y gestionar los requisitos.
Las etapas de la ingeniería de requisitos son:

Elicitación: Esta etapa consiste en identificar los requisitos del sistema

junto con el cliente, el problema y las necesidades reales para alcanzar
un consenso sobre los requisitos.

Análisis: Se enfoca en identificar y resolver conflictos en los requisitos y

profundizar en el conocimiento del problema, ajustando la comprensión
obtenida en la fase de elicitación.

Especificación: Se documentan los requisitos a nivel de detalle utilizando

las técnicas y/o estándares de documentación, como el UML (Lenguaje
de Modelado Unificado)

Validación: En esta fase se verifica que los requisitos documentados

correspondan realmente a las necesidades de clientes y usuarios. así
mismo permite reescribir algunas de los requisitos perfeccionar el
conjunto de requisitos documentados.