La ingeniería de requisitos es la disciplina que trata de desarrollar el

software correcto, tratando de obtener el producto que realmente

quiere o necesita el cliente.
Aunque tiene mucha relación con la ingeniería del software, no entra
en detalle de como desarrollar la aplicación sino solamente de que
cualidades tiene que tener para ser la aplicación que necesita el
cliente.
Así pues, la ingeniería de requisitos tiene como objeto identificar y
gestionar el conjunto de requisitos que darán como resultado el
software que vamos a desarrollar.
Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.

Una condición o capacidad que debe estar presente en un sistema o

componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal.
 Los stakeholders son todas las personas, usuarios y
entidades que tienen algún interés en el producto.
 Los requisitos son todas las características que
algún stakeholders puede esperar del producto.
Está formado por el conjunto de las siguientes tareas:

 Obtención de requisitos.
 Gestión de requisitos
 Documentación de requisitos
 Validación de requisitos
 Verificación de requisitos
 Diferencias entre los requisitos de los diferentes
stakeholders
 Limitaciones de los diferentes lenguajes de comunicación
 Dificultad para elegir los requisitos que pueden ser
mejores
Dentro de los requisitos que podemos encontrar
vamos a hacer una lista de los más frecuentes y
como agruparlos:
 Requisitos Funcionales
 Requisitos de funcionalidad
 Requisitos de datos
Dentro de los requisitos que podemos encontrar vamos a hacer
una lista de los más frecuentes y como agruparlos:

 Requisitos No funcionales
 Requisitos de Presentación
 Requisitos de usabilidad
 Requisitos de Cumplimiento
 Requisitos de entorno
 Requisitos Culturales
 Requisitos Legales
 Requisitos de proceso
En esta etapa obtendremos todos los requisitos que pueden necesitar
los distintos stakeholders, en muchos casos estos requisitos serán
iguales para distintos stakeholders.

En otros casos entrarán en conflicto por que no será viable realizar

ambos requisitos, no obstante en esta parte de obtención de requisitos
vamos a intentar recopila el mayor número de requisitos.

Todos los requisitos que hayamos obtenido en esta parte serán

requisitos candidatos que más tarde veremos si seguirán adelante en
el desarrollo de la aplicación.
En esta fase vamos a ver cuales de esos requisitos candidatos pasarán
a formar parte de los requisitos de producto, primero con un buen
análisis de requisitos que consisten en identificar bien los requisitos.

Después habrá que priorizar cuales son los requisitos por orden de
importancia ya que muchas veces no se pueden desarrollar
absolutamente todos los requisitos que necesita un cliente.

Ahora pasaríamos al momento de la estimación de estos requisitos,

para poder valorar económicamente cual es el precio de desarrollar
cada requisito.
En esta fase vamos a documentar los requisitos que finalmente se
desarrollarán. Es muy importante documentar bien esta parte porque
será de alguna manera el contrato entre lo que los desarrolladores y
los stakeholders trabajarán.

Para la documentación de requisitos será muy útil utilizar las historias

de usuario, los casos de uso y el lenguaje UML, que nos valdrán para
describir el nivel de detalle de los requisitos.
Llegados a esta fase ya tendremos los requisitos seleccionados y
documentados. En la documentación se reflejará las necesidades de
los stakeholders.
Para estar seguros de que esos requisitos son finalmente los que
vamos a desarrollar nos reuniremos de nuevo con los stakeholders y
explicaremos a modo de validación lo que finalmente se va a
desarrollar.
Después del desarrollo del software es necesario validar
con los stakeholders que los requisitos funcionan tal y como
habíamos documentado y validado en las fases anteriores.
Por lo que se realizarán las pruebas necesarias para lograr
la verificación de los requisitos.